Pregunta Convenciones de nomenclatura de bases de datos, tablas y columnas? [cerrado]


Cada vez que diseño una base de datos, siempre me pregunto si hay una mejor manera de nombrar un elemento en mi base de datos. Muy a menudo me hago las siguientes preguntas:

  1. ¿Los nombres de las tablas deben ser plurales?
  2. ¿Los nombres de las columnas deben ser singulares?
  3. ¿Debería prefijar tablas o columnas?
  4. ¿Debo usar cualquier caso para nombrar elementos?

¿Hay alguna recomendación recomendada para nombrar elementos en una base de datos?


631
2017-08-11 10:27


origen


Respuestas:


Recomiendo ver 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 consistente que utiliza nombres de esquema para la organización de objetos de base de datos.

  1. Nombres singulares para tablas
  2. Nombres singulares para columnas
  3. Nombre de esquema para el prefijo de tablas (por ejemplo, SchemeName.TableName)
  4. Caja Pascal (caja de camello superior)

245
2017-08-11 12:39



Última respuesta aquí, pero en resumen:

  1. Mi preferencia es plural
  2. Mesas: * Por lo general * no hay prefijos es mejor. Columnas: No.
  3. Ambas tablas y columnas: PascalCase.

Elaboración:

(1) Lo que debes hacer  Hay muy pocas cosas que debe hacer de cierta manera, todas las veces, pero hay algunas.

  • Nombra tu llaves principales usando el formato "[singularOfTableName] ID". Es decir, si su nombre de tabla es Cliente o Clientes, la clave principal debe ser Identificación del cliente.
  • Promover, llaves extranjeras debe ser nombrado constantemente en diferentes tablas Debería ser legal golpear a alguien que no hace esto. Yo diría que si bien las restricciones de clave externa definidas son a menudo el nombramiento de clave foránea importante y consistente es siempre importante
  • Tu base de datos debe tener convenciones internas. Aunque en secciones posteriores verás que soy muy flexible, dentro un nombre de base de datos debe ser muy consistente. Si su tabla para clientes se llama Clientes o Cliente es menos importante que hacerlo de la misma manera en la misma base de datos. Y puedes voltear una moneda para determinar cómo usar los guiones bajos, pero luego debe seguir utilizá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ía ser nombrado igual. No tiene Zip en una mesa y ZipCode en otra.
  • Para separar palabras en los nombres de su tabla o columna, use PascalCasing. Usar camelCasing no sería intrínsecamente problemático, pero esa no es la convención y se vería divertida. Voy a abordar los guiones bajos en un momento. (No puede usar ALLCAPS como en los viejos tiempos. OBNOXIOUSTABLE.ANNOYING_COLUMN estaba bien en DB2 hace 20 años, pero ahora no).
  • No acorte ni abrevie palabras. Es mejor para un nombre ser largo y claro que corto y confuso. Nombres ultra cortos es un vestigio de tiempos más oscuros y salvajes. Cus_AddRef. ¿Que demonios es eso? ¿Referencia del destinatario custodial? ¿Reembolso adicional del cliente? ¿Remisión de dirección personalizada?

(3) Lo que deberías considerar

  • Realmente creo que deberías tener nombres en plural para las tablas; algunos piensan en singular Lee los argumentos en otro lugar. Los nombres de las columnas deberían ser singulares sin embargo. Incluso si usa nombres de tablas plurales, las tablas que representan combinaciones de otras tablas pueden estar en singular. Por ejemplo, si tienes un Promociones y un Artículos tabla, una tabla que representa un elemento que forma parte de una promoción podría ser Promotions_Items, pero también podría ser legítimamente Promotion_Items, creo (que refleja la relación de uno a muchos).
  • Use guiones bajos consistentemente y para un propósito particular. Solo los nombres de las tablas generales deberían ser lo suficientemente claros con PascalCasing; no necesita guiones bajos para separar las palabras. Guarde guiones bajos ya sea (a) para indicar una tabla asociativa o (b) para el prefijo, que abordaré en el siguiente punto.
  • La prefijación no es ni buena ni mala. Eso generalmente no es lo mejor En su primer DB o dos, no sugeriría usar prefijos para la agrupación temática general de tablas. Las tablas terminan no ajustando sus categorías fácilmente, y realmente puede hacerlo Más fuerte para encontrar tablas. Con experiencia, puede planificar y aplicar un esquema de prefijación que hace más bien que dañar. Trabajé en un DB una vez que las tablas de datos comenzaron con tbl, config tablas con cbl, vistas con vew, proc spy udf fny algunos otros; fue meticulosamente aplicado de forma consistente, así que funcionó bien. La única vez que NECESITAS prefijos es cuando tienes soluciones realmente separadas que por alguna razón residen en el mismo db; prefijarlos puede ser muy útil para agrupar las tablas. La prefijación también está bien para situaciones especiales, como para las tablas temporales que desea destacar.
  • Muy raramente (si alguna vez) quieres para prefijar columnas.

215
2018-01-22 16:07



Ok, ya que estamos pesando 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. Entonces, yo llamaría a una tabla de Personas entidades Personas (o Personas, lo que sea que te apetezca).

Para aquellos a los que les gustaría ver "nombres de entidades" singulares en las consultas, para eso usaría alias de tabla para:

SELECT person.Name
FROM People person

Un poco como LINQ's "de persona en personas seleccione person.Name".

En cuanto a 2, 3 y 4, estoy de acuerdo con @Lars.


87
2017-08-11 10:49



Trabajo en un equipo de soporte de base de datos con tres DBA y nuestras opciones consideradas son:

  1. Cualquier nomenclatura estándar es mejor que ningún estándar.
  2. No hay un estándar "único verdadero", todos tenemos nuestras preferencias
  3. Si ya hay un estándar en su lugar, úselo. No cree otro estándar o enturbie los estándares existentes.

Usamos nombres singulares para tablas. Las tablas tienden a ser prefijadas con el nombre del sistema (o sus siglas). Esto es útil si el sistema es complejo, ya que puede cambiar el prefijo para agrupar las tablas lógicamente (es decir, reg_customer, reg_booking y regadmin_limits).

Para los campos esperamos que los nombres de campo incluyan el prefijo / acryonm de la tabla (es decir, cust_address1) y también preferimos el uso de un conjunto estándar de sufijos (_id para PK, _cd para "código", _nm para "nombre ", _nb para" number ", _dt para" Date ").

El nombre del campo clave Foriegn debe ser el mismo que el campo clave principal.

es decir

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

Al desarrollar un nuevo proyecto, le recomiendo que escriba todos los nombres de entidades, prefijos y acrónimos preferidos y entregue este documento a sus desarrolladores. Luego, cuando deciden crear una nueva tabla, pueden referirse al documento en lugar de "adivinar" a qué deben llamarse la tabla y los campos.


67
2017-08-11 12:24



  1. No. Una tabla debe nombrarse después de la entidad que representa. Persona, no personas es cómo se referiría a quien representa uno de los registros.
  2. De nuevo, lo mismo. La columna FirstName realmente no debería llamarse FirstNames. Todo depende de lo que quieras representar con la columna.
  3. NO.
  4. Sí. Caso por claridad. Si necesita columnas como "Nombre", la carcasa facilitará la lectura.

De acuerdo. Esa es mi $ 0.02


43
2017-08-11 10:35



También estoy a favor de una convención de nomenclatura de estilo ISO / IEC 11179, señalando que son pautas en lugar de ser prescriptivas.

Ver Nombre del elemento de datos en Wikipedia:

"Las tablas son colecciones de entidades y siguen las pautas de nombres de colección. Idealmente, se utiliza un nombre colectivo: por ejemplo, Personal. Plural también es correcto: Empleados. Los nombres incorrectos incluyen: Empleado, Empleado de tbl e Información de empleado".

Como siempre, hay excepciones a las reglas, p. una tabla que siempre tiene exactamente una fila puede ser mejor con un nombre singular, p. una tabla de config. Y la coherencia es de suma importancia: compruebe si compra tiene una convención y, de ser así, sígala; si no te gusta, haz un negocio para cambiarlo en lugar de ser el único explorador.


31
2017-10-23 10:45



nuestra preferencia:

  1. ¿Los nombres de las tablas deben ser plurales?
    Nunca. Los argumentos para que sea una colección tienen sentido, pero nunca se sabe qué contendrá la tabla (0,1 o muchos elementos). Las reglas plurales hacen innecesariamente complicada la nomenclatura. 1 casa, 2 casas, ratón vs ratones, persona vs personas, y ni siquiera hemos visto otros idiomas.

    Update person set property = 'value' actúa sobre cada persona en la mesa.
    Select * from person where person.name = 'Greg' devuelve una colección / conjunto de filas de filas de personas.

  2. ¿Los nombres de las columnas deben ser singulares?
    Por lo general, sí, excepto cuando está infringiendo las reglas de normalización.

  3. ¿Debería prefijar tablas o columnas?
    Principalmente una preferencia de plataforma. Preferimos prefijar columnas con el nombre de la tabla. No hacemos prefijos de tablas, pero sí prefijo views (v_) y stored_procedures (sp_ o f_ (function)). Eso ayuda a las personas que quieren probar upday v_person.age, que en realidad es un campo calculado en una vista (que no se puede ACTUALIZAR de todos modos).

    También es una gran manera de evitar la colisión de palabras clave (delivery.from breaks, pero delivery_from no lo hace).

    Hace que el código sea más detallado, pero a menudo ayuda en la legibilidad.

    bob = new person()
    bob.person_name = 'Bob'
    bob.person_dob = '1958-12-21'
    ... es muy legible y explícito. Esto puede salir de control sin embargo:

    customer.customer_customer_type_id

    indica una relación entre el cliente y la tabla customer_type, indica la clave principal en la tabla customer_type (customer_type_id) y si alguna vez ves 'customer_customer_type_id' mientras depura una consulta, sabes al instante de dónde es (tabla de clientes).

    o donde tiene una relación M-M entre tipo_cliente y categoría_cliente (solo ciertos tipos están disponibles para ciertas categorías)

    customer_category_customer_type_id

    ... es un poco (!) en el lado largo.

  4. ¿Debo usar cualquier caso para nombrar elementos? Sí, minúscula :), con guiones bajos. Estos son muy legibles y multiplataforma. Junto con 3 arriba también tiene sentido.

    La mayoría de estas son preferencias sin embargo. - Mientras seas consecuente, debería ser predecible para cualquiera que tenga que leerlo.


24
2018-03-26 13:58