Consejo sobre PK en el diseño de bases de datos

Estuve leyendo un excelente artículo sobre DB en el siguiente blog : http://grunch.com.ve/2007/05/20/estandarizacion-de-bases-de-datos-postgresql/

y me doy a la tarea de corregir una regla que se indica ahi:
Bueno, creo que esta regla: Toda tabla debe tener un Primary Key, siempre va a ser un campo serial/bigserial con el nombre “id”.
y tomando el ejemplo:
una tabla de facturación (id, nro_factura, cod_empresa…)

Esta regla NO es del todo cierta y "malcria" a los DBA, los hace tercos y perezosos y complica el diseño de capas de datos y gestión de persistencia de datos a los desarrolladores, les explico por que;

Una tabla puede tener un PK (primary Key) que sea igualmente compuesto y ayuda mejor en las consultas (que tener que incluir un serial que no nos ayuda en mucho); si me vas a buscar en una tabla como ejemplo, CNE.electores, es mejor V-13264658 (equivale a electores.nacionalidad, electores.cedula) (que soy yo) que un serial (en la idea de electores.id) 152227276353 es cual no es "naturalmente" correspondiente a mi mismo.

id(mas "underscore" mas "algo") debería ser la forma más optima (y estandar) de nominar los campos PK (o simplemente nominarlos y crear un indice PK) y no simplemente id a secas, en el caso de usar un ID a secas; ¿como haces una tabla de muestreo geográfico cuando las tablas de nivel inferior tienen PK que son la composición de varios indices de sus tablas madre? ej:
pais->estado->municipio->parroquia->sector->barrio

tu caso:
paises.id as id_pais, estados.id as id_estado, municipio.id as id_municipio

ves la parte?

en tu caso, una factura sería id_factura y no id a secas…
quiero el id del producto y el id del cliente de una factura x.

en tu caso, ocurriria que:

SELECT facturas.id as id_factura, clientes.id as id_cliente, productos.id as id_producto FROM facturas
LEFT JOIN productos ON productos.id = facturas.id_producto? (re-denominar el campo?)
LEFT JOIN clientes ON clientes.id = facturas.id_cliente? (re-denominar el campo?)
WHERE
clientes.id = 1 AND factura.id = x AND productos.nombre = 'Igotin'

Moriras usando un alias en los campos y redenominando los campos en los FK de cada tabla, cuando puedes hacer directamente:

SELECT facturas.id_factura, clientes.id_cliente, productos.id_producto FROM facturas
LEFT JOIN productos USING (id_producto)
LEFT JOIN clientes USING (id_cliente)
WHERE facturas.id_cliente = 1 AND facturas.id_factura = x AND productos.nombre_producto = 'Igotin'

Bueno, con que sentencia SQL me teñiré las canas mañana?

Espero les ayude este consejo a denominar "mejor" los campos y sobre todo, los indices primarios.

Acerca de phenobarbital

http://about.me/phenobarbital

Publicado el 20 mayo 2007 en Linux, PlanetaLinux, Programacion. Añade a favoritos el enlace permanente. 3 comentarios.

  1. Miguel Ortega

    Muy buenos días, veo que mi amigo Grunch se encargo de publicar un pequeño documento que redactamos como un intento vago de hacer un estandar dentro de la oficina. Leo tus comentarios y los agradezco.

    Quería hacer dos comentarios al respecto,el uso del nombre id para nosotros es indiferente ya que muy rara vez usemos un SELECT que llame a los ids de las tablas madre; es decir, clientes.id estaria como factura.id_cliente y cosas así.

    El segundo punto, y tal vez error mio no comentarlo…. El uso de un serial PK DEBE ser acompañado por una Clave UNIQUE que se indexa automaticamente (si mal no recuerdo) es decir tienes una tabla electores que debe contener al menos (id,cedula,nombre) con un PK (id) y un UNIQUE (cedula)…

    Espero podamos seguir conversando del tema, no soy experto pero hago lo que puedo!!!

    PD: Si tienen la oportunidad, agreguenle al documento NO usar FLOAT8 para campos que guarden valores de moneda, en vez de este, usar NUMERIC. Muchas Gracias a la lista de PostgreSQL. Hasta el mas novato es un tremendo prospecto y defensor de PostgreSQL.

    Saludos

  2. Simon A. Bolivar A.

    me estoy iniciando en programacion, de hecho administro un sistema administrativo y noto que la base de dato tiene una estructura como la mendiconas

    FTI_visiblre—-FTI_nombre—–FTI_cedula____FTI_XXXXX

  3. David Villarroel

    Hola a todos, me parece muy interesante el articulo y considero que el uso de un solo campo de clave primaria, simplifica bastante las referencias relacionales entre tablas en comparación con una clave primaria compuesta, asi que se hace muy conveniente en muchos casos su uso preferiblemente que utilizar una superclave compuesta, facilitando asi las consultas relacionales que involucren varias tablas y las referencias directas a un campo en una tabla. Por supuesto es conveniente indexar los campos clave de busqueda como la cedula o codigos o nombre de producto, etc. ademas de garantizar la integridad de los datos estableciendo las respectivas restricciones de unicidad, etc.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: