Consejo sobre PK en el diseño de bases de datos
Sunday, May 20th, 2007Estuve 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.
