¿Por qué especificar atributos de clave primaria / foránea en los nombres de columna?

Question

Un par de preguntas recientes discuten estrategias para nombrar columnas, y me sorprendió descubrir el concepto de incrustar la noción de claves primarias y externas en los nombres de las columnas. Eso es

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo_pk = t2.id_foo_fk

Debo confesar que nunca he trabajado en ningún sistema de base de datos que use este tipo de esquema, y ??me pregunto cuáles son los beneficios. A mi modo de ver, una vez que haya aprendido las N tablas principales de un sistema, escribirá varios órdenes de magnitud más solicitudes con esas tablas.

Para ser productivo en el desarrollo, deberá aprender qué tablas son las tablas importantes y cuáles son tributarios simples. Querrá cometer un buen número de nombres de columna en la memoria. Y una de las tareas básicas es unir dos tablas juntas. Para reducir el esfuerzo de aprendizaje, lo más fácil es asegurarse de que el nombre de la columna sea el mismo en ambas tablas:

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo = t2.id_foo

Creo que, como desarrollador, no necesitas que te recuerden que muchas de las columnas son claves principales, cuáles son externas y cuáles no son nada. Es bastante fácil mirar el esquema si tienes curiosidad. Cuando se mira al azar

tx inner join ty on tx.id_bar = ty.id_bar

... ¿es tan importante saber cuál es la clave externa? Las claves externas son importantes solo para el motor de base de datos, para permitirle garantizar la integridad referencial y hacer lo correcto durante las actualizaciones y eliminaciones.

¿Qué problema se está resolviendo aquí? (Sé que esto es una invitación para discutir, y siéntase libre de hacerlo. Pero al mismo tiempo, estoy buscando una respuesta, ya que es posible que me falte algo).

Answer 1

Estoy de acuerdo con usted en que la columna de clave externa en una tabla secundaria debe tener el mismo nombre que la columna de clave principal en la tabla principal. Tenga en cuenta que esto permite una sintaxis como la siguiente:

SELECT * FROM foo JOIN bar USING (foo_id);

La palabra clave USING supone que existe una columna con el mismo nombre en ambas tablas y que desea una unión equitativa. Es bueno tener esto disponible como taquigrafía para los más detallados:

SELECT * FROM foo JOIN bar ON (foo.foo_id = bar.foo_id);

Sin embargo, tenga en cuenta que hay casos en los que no puede nombrar la clave externa igual a la clave principal a la que hace referencia. Por ejemplo, en una tabla que tiene una referencia propia:

CREATE TABLE Employees (
  emp_id INT PRIMARY KEY,
  manager_id INT REFERENCES Employees(emp_id)
);

También una tabla puede tener varias claves externas para la misma tabla principal. Es útil usar el nombre de la columna para describir la naturaleza de la relación:

CREATE TABLE Bugs (
  ...
  reported_by INT REFERENCES Accounts(account_id),
  assigned_to INT REFERENCES Accounts(account_id),
  ...
);

No me gusta incluir el nombre de la tabla en el nombre de la columna. También evito el obligatorio " id " como el nombre de la columna de clave principal en cada tabla.

Answer 2

Estoy de acuerdo contigo. Poner esta información en el nombre de la columna huele a la idiotez de la notación húngara de los primeros días de Windows.

Answer 3

He defendido la mayoría de las ideas propuestas aquí durante los últimos 20 años que he estado desarrollando con bases de datos SQL, me da vergüenza decir. La mayoría de ellos proporcionaron pocos o ninguno de los beneficios esperados y fueron, en retrospectiva, un dolor en el cuello.

Cada vez que he pasado más de unas pocas horas con un esquema, me he familiarizado bastante rápidamente con las tablas más importantes y sus columnas. Una vez que pasen algunos meses, tendría todo en mi cabeza.

¿Para quién es toda esta explicación? Alguien que solo pasa unos minutos con el diseño no va a hacer nada serio de todos modos. Alguien que planee trabajar con él durante mucho tiempo lo aprenderá si nombraste las columnas en sánscrito.

Ignorando las claves primarias compuestas, no veo por qué algo tan simple como " id " no será suficiente para una clave primaria y '' _id '' para claves foráneas.

Por lo tanto, una condición de unión típica se convierte en customer.id = order.customer_id .

Cuando exista más de una asociación entre dos tablas, me inclinaría a usar la asociación en lugar del nombre de la tabla, por lo que quizás '' parent_id '' y '' child_id '' en lugar de " parent_person_id " etc

Answer 4

Solo uso el nombre de la tabla con un sufijo de ID para la clave principal, p. ej. CustomerId, y las claves externas que hacen referencia a otras tablas también se llamarían CustomerId. Cuando hace referencia a la aplicación, se hace evidente la tabla de las propiedades del objeto, por ejemplo. Customer.TelephoneNumber, Customer.CustomerId, etc.

Answer 5

He usado " fk_ " en el extremo frontal de cualquier clave externa para una tabla, principalmente porque me ayudó a mantenerla recta cuando desarrollé la base de datos para un proyecto en mi tienda. Al no haber hecho ningún trabajo de DB en el pasado, esto me ayudó. En retrospectiva, tal vez no necesitaba hacer eso, pero eran tres caracteres añadidos a algunos nombres de columna, así que no me molesté.

Al ser un recién llegado a la escritura de aplicaciones de DB, es posible que haya tomado algunas decisiones que harían temblar a un desarrollador de DB experimentado, pero no estoy seguro de que la clave externa sea realmente una gran cosa. Una vez más, supongo que es una diferencia en el punto de vista sobre este tema y ciertamente tomaré lo que ha escrito y meditaré sobre él.

Que tengas un buen

Answer 6

Estoy de acuerdo con usted: adopto un enfoque diferente que he visto recomendado en muchos entornos corporativos:

Columnas de nombre en el formato TableNameFieldName , por lo que si tuviera una tabla Customer y UserName fuera uno de mis campos, el campo se llamaría CustomerUserName. Eso significa que si tuviera otra tabla llamada Factura y el nombre de usuario del cliente fuera una clave externa, la llamaría InvoiceCustomerUserName, y cuando la referenciara, la llamaría Invoice.CustomerUserName, que inmediatamente me dice en qué tabla está.

Además, este nombre le ayuda a realizar un seguimiento de las tablas de las que provienen sus columnas cuando se une.

Solo uso FK_ y PK_ en los nombres REALES de las claves externas y primarias en el DBMS.