Después de investigar con especialistas en la materia, programadores de diversas ramas y profesores hemos dado con la respuesta al problema y la compartimos en esta publicación.
Solución:
Recomiendo consultar las bases de datos de ejemplo de SQL Server de Microsoft: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks
El ejemplo de AdventureWorks utiliza una convención de nomenclatura muy clara y coherente que utiliza nombres de esquema para la organización de los objetos de la base de datos.
- Nombres singulares para tablas
- Nombres singulares para columnas
- Nombre de esquema para tablas prefix (Por ejemplo: SchemeName.TableName)
- Caja de Pascal (también conocida como caja de camello superior)
Respuesta tardía aquí, pero en resumen:
- Nombres de tablas en plural: Mi preferencia es plural
- Nombres de columnas singulares: sí
- Prefijo tablas o columnas:
- Mesas: *Usualmente* sin prefijos es lo mejor.
- columnas: No.
- Use cualquier caso para nombrar elementos: PascalCase tanto para tablas como para columnas.
Elaboración:
(1) Lo que debes hacer. Hay muy pocas cosas que Ud. deber hacer de cierta manera, cada vez, pero hay unos pocos.
- Nombra tu primario keys utilizando “[singularOfTableName]ID”. Es decir, si el nombre de su tabla es Cliente o Clientesel primario key debiera ser Identificación del cliente.
- Más, extranjero keys deber ser nombrado consistentemente en diferentes tablas. Debería ser legal golpear a alguien que no hace esto. Yo diría que si bien se define extranjero key las restricciones son con frecuencia extranjero importante y consistente key nombrar es siempre importante
- Tu base de datos debe tener convenciones internas. Aunque en secciones posteriores me verás siendo muy flexible, dentro de la denominación de una base de datos debe ser muy consistente. Si su mesa para clientes se llama Clientes o Cliente es menos importante que lo hagas de la misma manera en la misma base de datos. Y puede lanzar una moneda para determinar cómo usar los guiones bajos, pero luego hay que seguir usándolos de la misma manera. Si no haces esto, eres una mala persona que debería tener baja autoestima.
(2) Lo que probablemente deberías hacer.
- Campos que representan el mismo tipo de datos en diferentes tablas deberían llamarse igual. No tenga Zip en una tabla y ZipCode en otra.
- Para separar palabras en los nombres de sus tablas o columnas, use PascalCasing. Usar camelCasing no sería intrínsecamente problemático, pero esa no es la convención y se vería divertido. Me ocuparé de los guiones bajos en un momento. (No puede usar MAYÚSCULAS como en los viejos tiempos. OBNOXIOUSTABLE.ANNOYING_COLUMN estaba bien en DB2 hace 20 años, pero no ahora).
- No acorte ni abrevie artificialmente las palabras. Es mejor que un nombre sea largo y claro que corto y confuso. Los nombres ultracortos son un remanente de tiempos más oscuros y salvajes. Cus_AddRef. ¿Que demonios es eso? ¿Referencia del destinatario de la custodia? ¿Reembolso adicional del cliente? ¿Referencia de dirección personalizada?
(3) Lo que debes considerar.
- Realmente creo que deberías tener nombres en plural para las tablas; algunos piensan singular. Lea los argumentos en otra parte. Sin embargo, los nombres de las columnas deben ser singulares. Incluso si usa nombres de tablas en plural, las tablas que representan combinaciones de otras tablas pueden estar en singular. Por ejemplo, si tienes un Promociones y un Elementos table, una tabla que representa un elemento que forma parte de una promoción podría ser Promotions_Items, pero creo que también podría ser legítimamente Promotion_Items (que refleja la relación de uno a muchos).
- Use guiones bajos consistentemente y para un propósito particular. Solo los nombres generales de las tablas deberían ser lo suficientemente claros con PascalCasing; no necesita guiones bajos para separar palabras. Guarde los guiones bajos (a) para indicar una tabla asociativa o (b) para el prefijo, que abordaré en la siguiente viñeta.
- Los prefijos no son ni buenos ni malos. Eso generalmente no es lo mejor En su primera base de datos o dos, no sugeriría usar prefijos para la agrupación temática general de tablas. Las tablas terminan no encajando fácilmente en sus categorías, y en realidad pueden hacerlo más difícil para encontrar mesas. Con experiencia, puede planificar y aplicar un esquema de prefijo que hace más bien que mal. Una vez trabajé en una base de datos donde las tablas de datos comenzaban con problematablas de configuración con ctblvistas con vistaproceso spy udf fn, y algunos otros; se aplicó de manera meticulosa y consistente, por lo que funcionó bien. La única vez que NECESITA prefijos es cuando tiene soluciones realmente separadas que, por alguna razón, residen en la misma base de datos; ponerles un prefijo puede ser muy útil para agrupar las tablas. El prefijo también está bien para situaciones especiales, como tablas temporales que desea destacar.
- Muy rara vez (si alguna vez) querrías prefix columnas
Ok, ya que estamos sopesando con la opinión:
Creo que los nombres de las tablas deben ser plurales. Las tablas son una colección (una tabla) de entidades. Cada fila representa una sola entidad y la tabla representa la colección. Así que yo llamaría a una tabla de entidades Personas Personas (o Personas, lo que te apetezca).
Para aquellos a quienes les gusta ver “nombres de entidad” singulares en las consultas, eso es para lo que usaría alias de tabla:
SELECT person.Name
FROM People person
Un poco como “from person in people select person.Name” de LINQ.
En cuanto a 2, 3 y 4, estoy de acuerdo con @Lars.
valoraciones y comentarios
Recuerda algo, que tienes la opción de esclarecer .