Convenios de denominación de nombres de columna y mejores prácticas

19

Quisiera alguna opinión experta sobre las mejores prácticas cuando se trata de nombrar columnas .

El trasfondo es que según Wikipedia , la siguiente sintaxis,

SELECT ... FROM Employees JOIN Timesheets USING (EmployeeID);

es más eficiente que

SELECT ... FROM Employees JOIN Timesheets ON (Employees.EmployeeID = Timesheets.EmployeeID);

Sin embargo, la JOIN ... USINGsintaxis solo funciona de todas las columnas de clave principal que tienen nombres únicos a nivel mundial . Por lo tanto, me pregunto si esto se considera lo correcto.

Personalmente, siempre solía crear tablas con columna PK idy columna de clave externa othertable_id. Pero de esa manera no es posible usar USINGo NATURAL JOIN.

¡Cualquier enlace a estilos de diseño o guías de mejores prácticas para el diseño de mesas también sería apreciado!

database-design join naming-convention Kerrek SB
fuente
3
Wikipedia está mal. La primera versión no es más eficiente que la segunda. Bajo el capó la base de datos creará Absolut consultas idénticas
a_horse_with_no_name

Respuestas:

13

Esto se ha preguntado antes en SO.

Donde tenga nombres comunes y muy ambiguos, entonces prefije con el nombre de la tabla. Es decir, cualquier cosa que tengas que tener alias en casi todas las consultas.

Entonces, para una mesa de empleados, tendría

EmployeeID
EmployeeName
Comment
Salary
StartDate
EndDate
InsertedDateTime
...

Y Wikipedia en realidad dice:

Sin embargo, la construcción USING es más que un simple azúcar sintáctico, ya que el conjunto de resultados difiere del conjunto de resultados de la versión con el predicado explícito. Específicamente, cualquier columna mencionada en la lista USING aparecerá solo una vez, con un nombre no calificado, en lugar de una vez para cada tabla en la unión.

Esa es una columna menos. Nunca lo usarías de SELECT *todos modos, así que el punto es discutible ...

gbn
fuente
No había pensado en buscarme TAN tontamente. ¿Tiene enlaces a alguna pregunta SO particularmente buena? De todos modos, gracias, ¡me atendré a la "identificación única" de aquí en adelante!
Kerrek SB
@Kerrk SB: en realidad, no lo he hecho. Tiendo a ignorarlos porque cada uno recibe respuesta o se cierra rápidamente :-) Lo siento
gbn
Me gustaría ver esas preguntas similares en SO, si alguien puede desenterrar un enlace. Vine aquí porque no pude encontrar una pregunta allí, y estaba seguro de que ya la habría hecho. Sin embargo, inmediatamente encontré esta pregunta.
Nicholas Shanks
Estaba en programadores. SE. Una gran pelea de bollos para ti ... programmers.stackexchange.com/questions/114728/…
gbn
6

El siguiente libro habla sobre el uso de ID como un antipatrón SQL y saludo con el autor que lo es. http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?s=books&ie=UTF8&qid=1330025134&sr=1-1

Este es un problema particular cuando realiza informes complejos y necesita más de una identificación, ya que entonces debe usar un alias. El uso de la ID de nombre de tabla también facilita la identificación del FK correcto para unirse (ya que tienen el mismo nombre) y hace que sea menos probable que se produzcan errores al unirse al elemento incorrecto.

Dicho esto, muchas bases de datos no son compatibles con la sintaxis de USO, lo que hace que el problema que mencionó no sea un problema para estas bases de datos. si las estructuras de la mesa cambian Supongamos que agrega un campo llamado fecha de modificación a ambas tablas, no querría unirse en eso, pero la unión natural lo haría.

HLGEM
fuente
4

Es mejor dar explícitamente el nombre de la tabla y el nombre de la columna como Employees.EmployeeID con expresiones donde existe una unión

Eralper
fuente