Nomenclatura de tabla: ¿subrayado vs Camelcase? espacios de nombres? ¿Singular vs Plural?

89

He estado leyendo un par de preguntas / respuestas en StackOverflow tratando de encontrar la 'mejor', o debería decir, la forma aceptada, para nombrar tablas en una base de datos.

La mayoría de los desarrolladores tienden a nombrar las tablas según el lenguaje que requiera la base de datos (JAVA, .NET, PHP, etc.). Sin embargo, siento que esto no está bien.

La forma en que he estado nombrando tablas hasta ahora es algo como:

doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents

Las cosas que me preocupan son:

Legibilidad
Identificación rápida del módulo del que proviene la tabla (médicos || pacientes)
Fácil de entender, para evitar confusiones.

Me gustaría leer cualquier opinión sobre las convenciones de nomenclatura. Gracias.

database database-design

— MarioRicalde
fuente

180

Ser coherente es mucho más importante que el esquema particular que utilice.

— David Oneill
fuente

21

En otras palabras, sí, bien hecho, ha identificado algunos esquemas consistentes. ¡Manos a la obra!

— Phil H

3

+1 para el comentario. Además, en una nota al margen del esquema de nomenclatura actual, PascalCase es mejor, especialmente si no usa alias para las consultas SQL. De esta manera, puede usar camelcase en los nombres de las columnas de la tabla y Pascal Case en los nombres de las tablas.

— MarioRicalde

3

El uso de mayúsculas y minúsculas en Pascal / camel para los nombres de las tablas puede generar algunos problemas. Cada tabla tendrá un archivo en el sistema de archivos, y algunos de ellos no distinguen entre mayúsculas y minúsculas (por ejemplo, OSX).

— ismriv

2

@ismriv eso es solo un problema si eres inconsistente, si siempre te refieres a tablas / vistas / columnas con el mismo caso consistente, no deberías tener ningún problema, no ser perezoso al escribir estos nombres te hará ganar mucho ventaja más adelante al leer. El uso de PascalCase para tablas y camelCase para columnas ayuda a identificar el tipo de un nombre de un vistazo y también imita las convenciones comunes orientadas a objetos.

— TWiStErRob

Estoy totalmente de acuerdo en que la consistencia es clave, pero esta es una pregunta vieja y para las personas que usan plataformas de bases de datos más nuevas como Redshift y Snowflake que tienen por defecto todos los identificadores en mayúsculas o minúsculas, agregaría que es muy importante pensar en su convenciones de nomenclatura desde el principio. Optar por usar una convención de nomenclatura como Camel Case en estas plataformas puede causarle algunos dolores de cabeza innecesarios más adelante, por ejemplo, tendrá que usar identificadores entre comillas todo el tiempo y la resolución de nombres de objetos puede producir resultados inesperados.

— Nathan Griffiths

22

Normalmente uso PascalCase y las entidades son singulares:

DoctorMain
DoctorProfile
DoctorPatient

Imita las convenciones de nomenclatura para las clases de mi aplicación, manteniendo todo bastante ordenado, limpio, coherente y fácil de entender para todos.

— Justin Niessner
fuente

3

Sí Sí lo hago. Estoy un poco nublado esta mañana. Haciendo la edición ... gracias.

— Justin Niessner

3

También se conoce como "CapitalCase".

— corsiKa

3

Nunca escuché que se llamara "CapitalCase" en mis 30 años de experiencia. Lo he oído llamar más "caso camello" y el "caso Pascal" ha sido abordado más recientemente. Vine aquí para ver por qué la gente parece estar usando camel case para SQL cuando históricamente ha sido mayoritariamente insensible a mayúsculas y minúsculas. Ciertamente no quiero quedarme atrás de los tiempos.

— Sinthia V

@SinthiaV No sé sobre otros, pero en nuestro caso, dado que estamos usando un ORM JS (lamentablemente), las opciones fueron 1) romper la convención usando camelCase en la base de datos 2) romper la convención usando snake_case en JS 3) mapa camelCase en JS a snake_case en db. Sin pensarlo mucho, decidimos usar camelCase en la base de datos, y no ha sido tan malo, pero citar todo es un poco complicado.

— Andy

@SinthiaV es un comentario inútil, esto podría ser en el contexto de la pregunta SO real, PascalCase no es lo mismo que camelCase. PascalCase escribe en mayúscula la primera letra de cada palabra (incluyendo fundamentalmente la primera) mientras que camelCase solo escribe en mayúscula las palabras después de la primera. Para leer más: medium.com/better-programming/…

— curioso

11

La naturaleza de los soportes SQL no distingue entre mayúsculas y minúsculas Underscores_Scheme. Sin embargo, el software moderno admite cualquier tipo de esquema de nombres. Sin embargo, a veces algunos errores desagradables, errores o factores humanos pueden conducir a UPPERCASINGEVERYTHINGque aquellos que seleccionaron ambos Pascal_Casey el Underscore_Caseesquema vivan con todos sus nervios en buen lugar.

— terR0Q
fuente

10

Una agregación de la mayoría de los anteriores:

no confíe en el caso en la base de datos
no consideres el caso o el separador como parte del nombre, solo las palabras
use cualquier separador o caso que sea el estándar para su idioma

Luego, puede traducir fácilmente (incluso automáticamente) nombres entre entornos.

Pero agregaría otra consideración: puede encontrar que hay otros factores cuando se mueve de una clase en su aplicación a una tabla en su base de datos: el objeto de la base de datos tiene vistas, activadores, procesos almacenados, índices, restricciones, etc. también necesito nombres. Así, por ejemplo, es posible que solo acceda a tablas a través de vistas que normalmente son simplemente un simple "seleccionar * de foo". Estos pueden identificarse como el nombre de la tabla con solo un sufijo de '_v' o puede ponerlos en un esquema diferente. El propósito de una capa de abstracción tan simple es que se pueda expandir cuando sea necesario para permitir cambios en un entorno para evitar impactar en el otro. Esto no rompería las sugerencias de nomenclatura anteriores, solo algunas cosas más a tener en cuenta.

— KenFar
fuente

8

Yo uso guiones bajos. Hice un proyecto de Oracle hace algunos años, y parecía que Oracle forzó todos mis nombres de objetos a mayúsculas, lo que arruina cualquier esquema de carcasa. Realmente no soy un tipo de Oracle, así que tal vez hubo una forma de evitar esto que no conocía, pero me hizo usar guiones bajos y nunca volví.

— Rayo
fuente

2

En 11g y versiones posteriores, el caso parece conservarse si el nombre de la tabla está entre comillas dobles. Poniendo esto aquí para referencia futura. Sé con certeza que Postgres también lo hace, es posible que otros motores de base de datos no lo hagan.

— John O

8

Dado que la pregunta no es específica de una plataforma o motor de base de datos en particular, debo decir que para una máxima portabilidad, siempre debe usar nombres de tablas en minúsculas.

/ [a-z _] [a-z0-9 _] * / es realmente el único patrón de nombres que se traduce sin problemas entre diferentes plataformas. Las minúsculas alfanuméricas + el subrayado siempre funcionarán de forma coherente.

Como se mencionó en otra parte, los nombres de las relaciones (tablas) deben ser singulares: http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html

— rico remer
fuente

Estoy de acuerdo: el subrayado tiene menos problemas en comparación con Pascal o camel Casing. Especialmente cuando los nombres viajan a modelos, dto y frontend al final.

— Saulius

6

Tiendo a estar de acuerdo con la gente que dice que depende de las convenciones del lenguaje que estás usando (por ejemplo, PascalCase para C # y snake_case para Ruby).

Sin embargo, nunca camelCase.

— Mark Rendle
fuente

2

Ada: Pascal_Case_With_Underscores

— uetoyo

6

Esto no tiene sentido cuando desea acceder a la misma tabla en dos idiomas diferentes que tienen convenciones de nomenclatura diferentes.

— Daniel W.

5

Después de leer muchas otras opiniones, creo que es muy importante usar las convenciones de nomenclatura del lenguaje, la consistencia es más importante que las convenciones de nomenclatura solo si eres (y serás) el único desarrollador de la aplicación. Si desea legibilidad (que es de gran importancia), es mejor que utilice las convenciones de nomenclatura para cada idioma. En MySQL, por ejemplo, no sugiero usar CamelCase ya que no todas las plataformas distinguen entre mayúsculas y minúsculas. Así que aquí el subrayado va mejor.

— Vlad Manuel Mureșan
fuente

1

¡¡¡Totalmente de acuerdo!!! Especialmente con MySql cuando lo ejecutas en Windows, todo se vuelve del camelCasea camelcase. Entonces, tener un caso de serpiente es mucho mejor. Además, Modern software however supports any kind of naming schemeno tiene ninguna garantía de que yop escriba el código para la última versión del software. Especialmente para la base de datos, la actualización de la versión no es trivial cuando se piensa en los costos de regresión.

— Cherry

2

Estos son mis cinco centavos. Llegué a la conclusión de que si se utilizan bases de datos de diferentes proveedores para un proyecto, hay dos mejores formas:

Utilice guiones bajos.
Utilice caja de camello con comillas.

La razón es que algunas bases de datos convertirán todos los caracteres a mayúsculas y algunos a minúsculas. Entonces, si lo tiene myTable, se convertirá en MYTABLEo mytablecuando trabajará con DB.

— Pavel_K
fuente

1

Desafortunadamente, no existe una "mejor" respuesta a esta pregunta. Como dijo @David, la coherencia es mucho más importante que la convención de nomenclatura.

— Kane
fuente

1

existe una gran variabilidad sobre cómo separar las palabras, por lo que tendrá que elegir lo que más le guste; pero al mismo tiempo, parece que hay casi consenso en que el nombre de la tabla debe ser singular.

— Javier
fuente

1

Las convenciones de nomenclatura existen dentro del alcance de un idioma y los diferentes idiomas tienen diferentes convenciones de nomenclatura.

SQL no distingue entre mayúsculas y minúsculas de forma predeterminada; entonces, snake_case es una convención ampliamente utilizada. SQL también admite identificadores delimitados; entonces, caso mixto en una opción, como camelCase (Java, donde campos == columnas) o PascalCase (C #, donde tablas == clases y columnas == campos). Si su motor de base de datos no puede soportar el estándar SQL, ese es su problema. Puede decidir vivir con eso o elegir otro motor. (Y por qué C # tenía que ser diferente es un punto de agravio para aquellos de nosotros que codificamos en ambos).

Si tiene la intención de usar un solo idioma en sus servicios y aplicaciones, use las convenciones de ese idioma en todos los niveles. De lo contrario, utilice las convenciones del idioma más utilizadas en el dominio donde se usa ese idioma.

— Chris Golledge
fuente