Convenciones de nomenclatura de MySQL, ¿el nombre del campo debe incluir el nombre de la tabla?

Question

Un amigo me dijo que debería incluir el nombre de la tabla en el nombre de campo de la misma tabla, y me pregunto por qué? ¿Y debería ser así? Ejemplo:

(Table) Users 
(Fields) user_id, username, password, last_login_time 

veo que el prefijo 'usuario_' no tiene sentido ya que sé que ya es para un usuario. Pero me gustaría saber de usted también. nota: Estoy programando en php, mysql.

Answer 1

Estoy de acuerdo con usted. El único lugar en el que me siento tentado de poner el nombre de la tabla o una forma abreviada de él es en claves primarias y externas o si el nombre "natural" es una palabra clave.

Users: id or user_id, username, password, last_login_time 
Post: id or post_id, user_id, post_date, content 

Yo generalmente uso 'id' como nombre de campo clave primaria pero en este caso creo que user_id y post_id son perfectamente bien también. Tenga en cuenta que la fecha fue llamado 'post_date" porque 'fecha' es una palabra clave.

Al menos esa es mi convención. Su kilometraje puede variar.

Answer 2

Con los campos genéricos como 'id' y 'nombre', es bueno para poner el nombre de tabla en.

La razón es que puede ser confuso cuando se une a la escritura a través de múltiples tablas.

Preferencia personal, realmente, pero ese es el razonamiento detrás de esto (y siempre lo hago de esta manera).

Independientemente del método que elija, asegúrese de que sea coherente dentro del proyecto.

Answer 3

no veo ninguna razón para incluir el nombre de la tabla, es superfluo. en las consultas se puede hacer referencia a los campos como el nombre <mesa>. < nombre de campo > de todos modos (por ejemplo "user.id").

Answer 4

prefijar el nombre de la columna con el nombre de tabla es una forma de garantizar nombres de columnas únicas , lo que facilita la unión.

Pero es una práctica tediosa, especialmente si tenemos nombres de tabla largos. En general es más fácil usar alias cuando sea apropiado. Además, no ayuda cuando nos unimos a nosotros mismos.

Como modelador de datos, me resulta difícil ser constante todo el tiempo. Con columnas ID que teóricamente prefiere tener solo ID pero por lo general parece que tengo tablas con columnas llamadas USER_ID, ORDER_ID, etc.

Hay escenarios donde puede ser positivamente beneficioso utilizar un nombre de columna común de varias tablas. Por ejemplo, cuando una relación lógica de supertipo/subtipo se ha representado como solo las tablas secundarias, es útil retener la columna del superíndice en todas las tablas de subtipos (por ejemplo, ITEM_STATUS) en lugar de cambiar el nombre de cada sub -type (ORDER_ITEM_STATUS, INVOICE_ITEM_STATUS, etc.). Esto es particularmente cierto cuando se trata de enumeraciones con un conjunto común de valores.

Answer 5

Personalmente no agrego nombres de tabla para nombres de campo en la tabla principal, pero cuando lo uso como un campo foráneo en otra tabla, lo prefijo con el nombre de la tabla fuente. p.ej. El campo de identificación en la tabla de usuarios se denominará id, pero en la tabla de comentarios, donde los comentarios están vinculados al usuario que los publicó, será user_id.

Esto recogí del esquema de nombres de CakePHP y creo que es bastante limpio.

Answer 6

Por ejemplo, la base de datos tiene tablas que almacenan información sobre las ventas y los departamentos de recursos humanos, se podría nombrar todas las tablas relacionadas con el departamento de ventas, como se muestra a continuación:

SL_NewLeads SL_Territories SL_TerritoriesManagers

Usted podría nombrar todas las tablas relacionadas con el departamento de recursos humanos, como se muestra a continuación:

HR_Candidates HR_PremierInstitutes HR_InterviewSchedules

Este tipo de convención de nomenclatura se asegura de que todas las tablas relacionadas se agrupen cuando se enumeran todas las tablas en orden alfabético. Sin embargo, si su base de datos trata solo con un grupo lógico de tablas, no necesita usar esta convención de nomenclatura.

Tenga en cuenta que, a veces, termina particionando verticalmente las tablas en dos o más tablas, aunque estas particiones representan efectivamente la misma entidad. En este caso, añada una palabra que mejor identifique la partición, al nombre de la entidad

Answer 7

Suena como si la conclusión fuera Si el nombre del campo es único en todas las tablas: prefijo con el nombre de la tabla. Si el nombre del campo tiene el potencial de ser duplicado en otras tablas, nómbrelo único.

Encontré nombres de campo como "img, dirección, teléfono, año" ya que las diferentes tablas pueden incluir diferentes imágenes, direcciones, números de teléfono y años.

Answer 8

En realidad, hay una razón para ese tipo de nomenclatura, especialmente cuando se trata de campos, es probable que se unan. En MySQL al menos, puede usar la palabra clave USING en lugar de ON, luego users u JOIN posts p ON p.user_id = u.id se convierte en users u JOIN posts p USING(user_id), que es la IMO más limpia.

En cuanto a otros tipos de campos, puede beneficiarse al seleccionar *, ya que no tendría que especificar la lista de los campos que necesita y estar seguro de qué campo proviene de cada tabla. Pero generalmente se desaconseja el uso SELECT * por razones de rendimiento y mantenimiento, por lo que considero que el prefijo de dichos campos con el nombre de la tabla es una mala práctica, aunque puede diferir de una aplicación a otra.

Answer 9

Debemos definir las claves principales con el prefijo de tablename.

Deberíamos usar use_id en su lugar si id y post_id en lugar de solo id.

Beneficios: -

1) de fácil lectura

2) fácilmente diferenciar en consultas de unión. Podemos minimizar el uso de alias en la consulta.

tabla usuario: user_id (PK)

poste tabla: post_id (PK) user_id (FK) aquí PK tabla de usuario y la tabla de post FK son mismo

Según documentation,

3) de esta manera podemos obtener beneficio de reunión natural y unirse con el uso de

Uniones naturales y uniones con USING, incluidas las variantes de unión externa, son procesadas según el estándar SQL: 2003. El objetivo era alinear la sintaxis y la semántica de MySQL con respecto a NATURAL JOIN y ÚNETE ... USANDO según SQL: 2003. Sin embargo, estos cambios en el proceso de unión pueden dar como resultado columnas de salida diferentes para algunas combinaciones. Además, algunas consultas que parecían funcionar correctamente en las versiones anteriores (anteriores a la 5.0.12) se deben reescribir para cumplir con la norma.

Estos cambios tienen cinco aspectos principales:

1) La forma en que MySQL determina las columnas de resultados de NATURAL o el uso de operaciones de combinación (y así el resultado de la totalidad de la cláusula FROM).

2) Expansión de SELECT * y SELECT tbl_name. * En una lista de columnas seleccionadas.

3) Resolución de nombres de columna en NATURAL o UTILIZACIÓN de combinaciones.

4) Transformación de NATURAL o USING une en JOIN ... ON.

5) Resolución de los nombres de columnas en la condición ON de un JOIN ... ON.

Ejemplos: -

SELECT * FROM user NATURAL LEFT JOIN post; 
SELECT * FROM user NATURAL JOIN post; 
SELECT * FROM user JOIN post USING (user_id);