¿Existe una convención de nomenclatura para MySQL?


163

Así es como lo hago:

  1. Los nombres de las tablas están en minúsculas, usan guiones bajos para separar las palabras y son singulares (p foo. Ej . foo_bar, Etc.
  2. Generalmente (no siempre) tengo un PK de incremento automático. Utilizo la siguiente convención: tablename_id(por ejemplo foo_id, foo_bar_id, etc.).
  3. Cuando una tabla contiene una columna que es una clave externa, solo copie el nombre de la columna de esa clave de la tabla de la que provenga. Por ejemplo, digamos que la tabla foo_bartiene el FK foo_id(donde foo_ides el PK de foo).
  4. Cuando defino FK para hacer cumplir la integridad referencial, utilizo lo siguiente: tablename_fk_columnname(por ejemplo, si avanza el ejemplo 3, sería foo_bar_foo_id). Como se trata de una combinación de nombre de tabla / nombre de columna, se garantiza que será única dentro de la base de datos.
  5. Ordeno las columnas de esta manera: PK, FK, luego el resto de columnas alfabéticamente

¿Hay una manera mejor y más estándar de hacer esto?


66
¿Es incorrecto usar para PK de incremento automático solo "id"? ¿Por qué? El nombre de la columna solo tiene significado en el contexto de la tabla. Así que tengo un "id" en cada tabla, y puedo tener muchos id_ <table_name> para FK.
Zbyszek

3
@Zbyszek Creo que la razón más simple en contra de eso es simplemente por la consistencia / simplicidad. En lugar de tener id_tableB=> oh no hay una columna con un nombre diferente id , la consistencia de id_tableB=> id_tableBsimplemente se ve más ordenada ... o como lo hace OP: foo_id=> en foo_idlugar de foo_id=>id
Don Cheadle

Respuestas:


106

Yo diría que ante todo: ser coherente.

Creo que ya casi está allí con las convenciones que ha esbozado en su pregunta. Sin embargo, un par de comentarios:

Los puntos 1 y 2 son buenos, creo.

Punto 3: lamentablemente esto no siempre es posible. Piense en cómo manejaría una sola tabla foo_barque tiene columnas foo_idy another_foo_idlas cuales hacen referencia a la footablafoo_id columna de . Es posible que desee considerar cómo lidiar con esto. ¡Sin embargo, este es un caso de esquina!

Punto 4: similar al punto 3. Es posible que desee introducir un número al final del nombre de la clave externa para tener más de una columna de referencia.

Punto 5: evitaría esto. Le proporciona poco y se convertirá en un dolor de cabeza cuando desee agregar o eliminar columnas de una tabla en una fecha posterior.

Algunos otros puntos son:

Convenciones de nomenclatura de índice

Es posible que desee introducir una convención de nomenclatura para índices; esta será una gran ayuda para cualquier trabajo de metadatos de base de datos que desee realizar. Por ejemplo, es posible que solo desee llamar a un índice foo_bar_idx1o foo_idx1, totalmente de usted, pero vale la pena considerar.

Nombres de columnas singulares vs plurales

Puede ser una buena idea abordar el tema espinoso de plural vs simple en los nombres de las columnas, así como en los nombres de la tabla. Este tema a menudo causa grandes debates. en la comunidad DB. Me quedaría con formas singulares para los nombres de las tablas y las columnas. Ahí. Lo he dicho

¡Lo principal aquí es, por supuesto, la consistencia!


¿Qué sería mejor que el punto 5? ¿Por qué podría convertirse en un dolor de cabeza?
Rasshu

77
Para hacer un seguimiento, encontré este verry útil para aquellos que vendrán aquí más tarde: launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/…
Enissay

1
Tengo problemas para encontrar un buen "esquema" para nombrar mis tablas que contienen objetos de modelos que constan de dos nombres (DocumentChapter, DocumentVersion, DocumentType, etc.). Por ejemplo, para DocumentType podría nombrarlo documenttypeo document_type. Preferiría la última, pero la mayoría de las veces tengo una relación de muchos a muchos y necesito una mesa similar document_document_type. ¿Alguna sugerencia sobre cómo manejar esto?
lexith

@ rsb2097 Re: punto 5: después de agregar una columna (al final), el pedido podría dejar de ser válido. No debe agregar ninguna restricción que requiera reordenar las columnas, ya que es una sobrecarga innecesaria.
Will Sheppard

21

La consistencia es la clave de cualquier estándar de nombres. Mientras sea lógico y consistente, estará 99% allí.

El estándar en sí es una preferencia muy personal, así que si te gusta tu estándar, entonces ejecútalo.

Para responder a su pregunta directamente, no, MySQL no tiene una convención / estándar de nomenclatura preferida, por lo que rodar la suya está bien (y la suya parece lógica).



4

Afortunadamente, los desarrolladores de PHP no son "fanáticos de los casos de camellos" como algunas comunidades de desarrollo que conozco.

Tus convenciones suenan bien.

Siempre y cuando sean a) simples yb) consistentes: no veo ningún problema :)

PD: Personalmente, creo que 5) es excesivo ...


2
Lejos de ser fanáticos, muchas personas de la comunidad de DB desaprueban el caso de los camellos porque algunos de los RDBMS no distinguen entre mayúsculas y minúsculas hasta el punto en que eliminarán los casos (o cambiarán todo a mayúsculas) para que las cosas se pongan realmente feas de manera muy rápida.
mal-wan

@mwan: ¿puede especificar qué RDBMS '? Y yo también soy un jockey de camellos. Las mayúsculas solo tienen un propósito en mi esquema, indicar tablas de unión y (en el caso de campos) indicar límites de palabras, de modo que _ pueda ser exclusivamente para indicar un othertable_id (es decir, nombre de tabla = othertable y campo en esa tabla = id ) Además, si el otro RDBMS no distingue entre mayúsculas y minúsculas, ¿qué importa realmente? ¡Nunca voy a tener una versión en mayúsculas y minúsculas de la misma tabla! Ah, y no preferiría un RDBMS que no distinga entre mayúsculas y minúsculas. Prefiero escribir un código coherente
Samuel Fullman

77
Me gusta la ironía de los usuarios de MySQL que no les gusta CamelCase y el nombre del producto que usamos: MySQL, escrito en CamelCase
DBX12

1
@ DBX12 Para ser pedante, eso es PascalCase, no camelCase, pero su punto sigue en pie.
MarredCheese

@MarredCheese Nunca lo pensé, pero tienes razón. camelCase no debería tener joroba al comienzo.
DBX12

1

Respuesta simple: NO

Bueno, al menos una convención de nomenclatura como tal fomentada por Oracle o la comunidad, no, sin embargo, básicamente debe ser consciente de seguir las reglas y límites para los identificadores, como se indica en la documentación de MySQL: https://dev.mysql.com /doc/refman/8.0/en/identifiers.html

Sobre la convención de nomenclatura que sigues, creo que está bien, solo el número 5 es un poco innecesario, creo que la mayoría de las herramientas visuales para administrar bases de datos ofrecen una opción para ordenar los nombres de columna (uso DBeaver, y lo tiene), así que Si el propósito es tener una buena presentación visual de su tabla, puede usar esta opción que menciono.

Por experiencia personal, recomendaría esto:

  • Use minúsculas . Esto casi garantiza la interoperabilidad cuando migra sus bases de datos de un servidor a otro. A veces, el lower_case_table_namesno está configurado correctamente y su servidor comienza a arrojar errores simplemente al no reconocer su estándar camelCase o PascalCase (problema de mayúsculas y minúsculas).
  • Los nombres cortos . Simple y claro. Cuanto más fácil y rápido sea identificar su tabla o columnas, mejor. Confía en mí, cuando haces muchas consultas diferentes en un corto período de tiempo, es mejor tener todo simple para escribir (y leer).
  • Evita los prefijos . A menos que esté utilizando la misma base de datos para tablas de diferentes aplicaciones, no use prefijos. Esto solo agrega más verbosidad a sus consultas. Hay situaciones en las que esto podría ser útil, por ejemplo, cuando desea identificar claves primarias y claves externas, que generalmente los nombres de tabla se usan como prefijo para las columnas de identificación.
  • Use guiones bajos para separar palabras . Si aún desea usar más de una palabra para nombrar una tabla, columna, etc., use guiones bajos para separar_las_palabras , esto ayuda a la legibilidad (sus ojos y su cerebro estresado se lo agradecerán).
  • Se consistente . Una vez que tenga su propio estándar, sígalo. No sea la persona que crea las reglas y es el primero que las rompe, eso es vergonzoso.

¿Y qué pasa con el nombre "Plural vs Singular"? Bueno, esta es una situación de preferencias personales. En mi caso, trato de usar nombres plurales para tablas porque creo que una tabla es una colección de elementos o un paquete que contiene elementos, por lo que un nombre plural tiene sentido para mí; y nombres singulares para columnas porque veo columnas como atributos que describen singularmente a esos elementos de la tabla.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.