Convención de nomenclatura de clave principal / clave externa [cerrado]

En nuestro grupo de desarrollo, tenemos un intenso debate sobre la convención de nomenclatura de claves primarias y externas. Básicamente, hay dos escuelas de pensamiento en nuestro grupo:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

o

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

Prefiero no duplicar el nombre de la tabla en ninguna de las columnas (así que prefiero la opción 1 anterior). Conceptualmente, es consistente con muchas de las prácticas recomendadas en otros lenguajes, donde no se usa el nombre del objeto en sus nombres de propiedad. Creo que nombrar la clave externa EmployeeID(o Employee_IDpodría ser mejor) le dice al lector que es la IDcolumna de la EmployeeTabla.

Algunos otros prefieren la opción 2, en la que se nombra la clave principal con el prefijo del nombre de la tabla para que el nombre de la columna sea el mismo en toda la base de datos. Veo ese punto, pero ahora no puede distinguir visualmente una clave primaria de una clave externa.

Además, creo que es redundante tener el nombre de la tabla en el nombre de la columna, porque si piensa en la tabla como una entidad y una columna como una propiedad o atributo de esa entidad, piensa en ella como el atributo de ID del Employee, no el EmployeeIDatributo de un empleado. No voy a preguntarle a mi compañero de trabajo qué es PersonAgeo qué PersonGenderes. Le pregunto cuál es su edad.

Entonces, como dije, es un debate furioso y seguimos y seguimos al respecto. Estoy interesado en obtener nuevas perspectivas.

Realmente no importa. Nunca me he encontrado con un sistema en el que haya una diferencia real entre la opción 1 y la opción 2.

Jeff Atwood tenía un gran artículo hace un tiempo sobre este tema. Básicamente, las personas debaten y discuten con más furia aquellos temas en los que no se puede demostrar que estén equivocados. O desde un ángulo diferente, esos temas que solo se pueden ganar a través del estilo filibustero basados ​​en argumentos de último hombre en pie.

Elija uno y dígales que se concentren en los problemas que realmente afectan su código.

EDITAR: Si desea divertirse, pídales que especifiquen detalladamente por qué su método es superior para las referencias de tablas recursivas.

Si las dos columnas tienen el mismo nombre en ambas tablas (convención n. ° 2), puede usar la sintaxis USING en SQL para ahorrar algo de escritura y algo de ruido repetitivo:

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

Otro argumento a favor de la convención n. ° 2 es que es la forma en que se diseñó el modelo relacional .

La importancia de cada columna se transmite parcialmente etiquetándola con el nombre del dominio correspondiente.

Creo que depende de cómo esté preparada la solicitud. Si usa ORM o diseña sus tablas para representar objetos, la opción 1 puede ser para usted.

Me gusta codificar la base de datos como su propia capa. Yo controlo todo y la aplicación solo llama a los procedimientos almacenados. Es bueno tener conjuntos de resultados con nombres de columna completos, especialmente cuando hay muchas tablas unidas y muchas columnas devueltas. Con este tipo de aplicación, me gusta la opción 2. Realmente me gusta ver que los nombres de las columnas coincidan en las combinaciones. Trabajé en sistemas antiguos en los que no coincidían y fue una pesadilla,

Ninguna convención funciona en todos los casos, entonces, ¿por qué tener una? Usa el sentido común...

Por ejemplo, para la tabla de autorreferencia, cuando hay más de una columna FK que hace referencia al PK de la misma tabla, TIENE que violar ambos "estándares", ya que las dos columnas FK no pueden tener el mismo nombre ... , EmployeeTable con EmployeeId PK, SupervisorId FK, MentorId Fk, PartnerId FK, ...

Estoy de acuerdo en que hay poco para elegir entre ellos. Para mí, una cosa mucho más significativa acerca de cualquiera de los estándares es la parte "estándar".

Si la gente comienza a 'hacer lo suyo', sus nethers deberían colgarlos. EN MI HUMILDE OPINIÓN :)

¿Ha considerado lo siguiente?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

La convención que usamos donde trabajo es bastante cercana a A, con la excepción de que nombramos tablas en forma plural (es decir, "empleados") y usamos guiones bajos entre el nombre de la tabla y la columna. El beneficio de esto es que para hacer referencia a una columna, es "empleados _ id" o "empleados.id", dependiendo de cómo desee acceder a ella. Si necesita especificar de qué tabla proviene la columna, "employee.employees _ id" definitivamente es redundante.

Si está mirando el código de la aplicación, no solo las consultas de la base de datos, algunas cosas me parecen claras:

1. Las definiciones de tabla generalmente se asignan directamente a una clase que describe un objeto, por lo que deben ser singulares. Para describir una colección de un objeto, generalmente agrego "Matriz" o "Lista" o "Colección" al nombre singular, ya que más claramente que el uso de plurales indica no solo que es una colección, sino qué tipo de colección. es. En esa vista, veo el nombre de una tabla no como el nombre de la colección, sino como el nombre del tipo de objeto del que es una colección. Un DBA que no escribe código de aplicación podría perder este punto.

2. Los datos que trato a menudo utilizan "ID" para fines de identificación no clave. Para eliminar la confusión entre los "ID" de clave y los "ID" que no son de clave, para el nombre de la clave principal, usamos "Clave" (eso es lo que es, ¿no es así?) Prefijado con el nombre de la tabla o una abreviatura de el nombre de la tabla. Este prefijo (y lo reservo solo para la clave principal) hace que el nombre de la clave sea único, lo cual es especialmente importante porque usamos nombres de variables que son los mismos que los nombres de las columnas de la base de datos, y la mayoría de las clases tienen un padre, identificado por el nombre de la clave principal. Esto también es necesario para asegurarse de que no se trata de una palabra clave reservada, que sólo es "Clave". Para facilitar la coherencia de los nombres de las variables clave y proporcionar programas que realicen uniones naturales, las claves externas tienen el mismo nombre que se utiliza en la tabla en la que son la clave principal. Más de una vez he encontrado programas que funcionan mucho mejor de esta manera usando uniones naturales. Sobre este último punto, admito un problema con las tablas de autorreferencia, que he utilizado. En este caso, haría una excepción a la regla de denominación de claves foráneas. Por ejemplo, usaría ManagerKey como una clave externa en la tabla Empleado para apuntar a otro registro en esa tabla.

Me gusta la convención n. ° 2: al investigar este tema y encontrar esta pregunta antes de publicar la mía, me encontré con el problema donde:

Estoy seleccionando * de una tabla con una gran cantidad de columnas y uniéndolo a una segunda tabla que también tiene una gran cantidad de columnas. Ambas tablas tienen una columna "id" como clave principal, y eso significa que tengo que seleccionar específicamente cada columna (hasta donde yo sé) para que esos dos valores sean únicos en el resultado, es decir:

SELECT table1.id AS parent_id, table2.id AS child_id

Aunque usar la convención n. ° 2 significa que todavía tendré algunas columnas en el resultado con el mismo nombre, ahora puedo especificar qué identificación necesito (padre o hijo) y, como sugirió Steven Huwig, la USINGdeclaración simplifica aún más las cosas.

Siempre he usado userId como PK en una tabla y userId en otra tabla como FK. Estoy pensando seriamente en usar userIdPK y userIdFK como nombres para identificar uno del otro. Me ayudará a identificar PK y FK rápidamente cuando mire las tablas y parece que borrará el código cuando use PHP / SQL para acceder a los datos, lo que facilita su comprensión. Especialmente cuando alguien más mira mi código.

Yo uso la convención n. ° 2. Ahora estoy trabajando con un modelo de datos heredado en el que no sé qué significa en una tabla determinada. ¿Dónde está el daño en ser prolijo?

¿Qué tal nombrar la clave externa?

Identificación del rol

donde rol es el rol que la entidad referenciada tiene en relación con la mesa en cuestión. Esto resuelve el problema de la referencia recursiva y múltiples fks a la misma tabla.

En muchos casos será idéntico al nombre de la tabla referenciada. En estos casos se vuelve idéntico a una de sus propuestas.

En cualquier caso, tener largas discusiones es una mala idea.

"¿En qué parte de" pedido INNER JOIN del empleado EN order.employee_id = employee.id "hay una necesidad de calificación adicional?".

No hay necesidad de una calificación adicional porque la calificación de la que hablé ya está ahí.

"la razón por la que un usuario empresarial se refiere a la ID de pedido o la ID de empleado es para proporcionar contexto, pero a nivel de base de datos ya tiene contexto porque está haciendo referencia a la tabla".

Por favor, dígame, si la columna se llama 'ID', entonces ¿cómo se hace exactamente esa "referencia [sic] a la tabla", a menos que califique esta referencia a la columna de ID exactamente de la forma en que hablé?