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

StackOverflow https://stackoverflow.com/questions/7662

Pregunta

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

  1. ¿Deben los nombres de las tablas estar en plural?
  2. ¿Deben los nombres de las columnas ser singulares?
  3. ¿Debo anteponer tablas o columnas?
  4. ¿Debo utilizar algún caso para nombrar elementos?

¿Existen pautas recomendadas para nombrar elementos en una base de datos?

¿Fue útil?

Solución

Recomiendo consultar las bases de datos de muestra 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.

  1. Nombres singulares para tablas.
  2. Nombres singulares para columnas.
  3. Nombre de esquema para el prefijo de tablas (por ejemplo:NombreEsquema.NombreTabla)
  4. Carcasa Pascal (también conocida comomayúscula camello)

Otros consejos

Respuesta tardía aquí, pero en resumen:

  1. Mi preferencia es plural
  2. Sí
  3. Mesas:*Por lo general* lo mejor es no tener prefijos. columnas:No.
  4. Tanto tablas como columnas:Caso Pascal.

Elaboración:

(1) Lo que debes hacer. Hay muy pocas cosas que tu debe hacerlo de cierta manera, cada vez, pero hay algunas.

  • Nombra tu claves primarias usando el formato "[singularOfTableName]ID".Es decir, si el nombre de su tabla es Cliente o Clientes, la clave principal debe ser Identificación del cliente.
  • Más, llaves extranjeras debe ser nombrado consistentemente 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 La denominación de claves externas importante y consistente es siempre importante
  • Su base de datos debe tener convenciones internas.Aunque en secciones posteriores me verás siendo muy flexible, dentro el nombre 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 toda la misma base de datos.Y puedes lanzar una moneda para determinar cómo usar 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ía llamarse igual.No tenga Zip en una mesa 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 parecería divertido.Me ocuparé de los guiones bajos en un momento.(No puedes usar ALLCAPS como en los viejos tiempos.OBNOXIOUSTABLE.ANNOYING_COLUMN estaba bien en DB2 hace 20 años, pero no ahora).
  • No acortes ni abrevies palabras artificialmente.Es mejor que un nombre sea largo y claro que corto y confuso.Los nombres ultracortos son un vestigio de tiempos más oscuros y salvajes.Cus_AddRef.¿Que demonios es eso?¿Referencia del destinatario de custodia?¿Reembolso adicional al 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 en singular.Lea los argumentos en otra parte.Sin embargo, los nombres de las columnas deben ser singulares.Incluso si utiliza 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 tabla, una tabla que representa un artículo que forma parte de una promoción podría ser Promotions_Items, pero creo que también podría ser legítimamente Promotion_Items (lo que refleja la relación de uno a muchos).
  • Utilice guiones bajos de forma consistente y para un propósito particular.Sólo los nombres generales de las tablas deberían quedar lo suficientemente claros con PascalCasing;no necesitas guiones bajos para separar palabras.Guarde los guiones bajos (a) para indicar una tabla asociativa o (b) para prefijar, lo cual abordaré en el siguiente punto.
  • El prefijo no es ni bueno ni malo.Él generalmente no es lo mejor.En su primera o dos bases de datos, no sugeriría el uso de prefijos para la agrupación temática general de tablas.Las tablas terminan no encajando fácilmente en sus categorías y, de hecho, pueden hacerlo. más difícil para encontrar tablas.Con experiencia, podrá planificar y aplicar un esquema de prefijos que haga más bien que mal.Una vez trabajé en una base de datos donde las tablas de datos comenzaban con tbl, tablas de configuración con ctbl, vistas con vista, procesos sp, y 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;prefijarlos puede ser muy útil para agrupar las tablas.Los prefijos también están bien para situaciones especiales, como tablas temporales que desea destacar.
  • Muy rara vez (si alguna vez) querrías prefijo columnas.

Ok, ya que estamos opinando:

Creo que los nombres de las tablas deberían estar en plural.Las tablas son una colección (una tabla) de entidades.Cada fila representa una única entidad y la tabla representa la colección.Entonces llamaría a una tabla de entidades Persona Personas (o Personas, como prefieras).

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

SELECT person.Name
FROM People person

Un poco como "de persona en personas selecciona persona. Nombre" de LINQ.

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

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

  1. Cualquier estándar de nomenclatura es mejor que ningún estándar.
  2. No existe un estándar "único", todos tenemos nuestras preferencias
  3. Si ya existe un estándar, utilícelo.No cree otro estándar ni enturbie los estándares existentes.

Usamos nombres singulares para las tablas.Las tablas tienden a tener el prefijo del nombre del sistema (o su acrónimo).Esto es útil si el sistema es complejo, ya que puede cambiar el prefijo para agrupar las tablas de forma lógica (es decir,reg_customer, reg_booking y regadmin_limits).

Para los campos, esperaríamos que los nombres de los campos 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 "número", _dt para "Fecha").

El nombre del campo de clave externa debe ser el mismo que el del campo de 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, prefijos y acrónimos de entidades preferidos y entregue este documento a sus desarrolladores.Luego, cuando deciden crear una nueva tabla, pueden consultar el documento en lugar de "adivinar" cómo se deben llamar la tabla y los campos.

  1. No.Una tabla debe llevar el nombre de la entidad que representa.Persona, no personas, es como se referiría a quienquiera que represente uno de los registros.
  2. De nuevo, lo mismo.La columna Nombre realmente no debería llamarse Nombres.Todo depende de lo que quieras representar con la columna.
  3. NO.
  4. Sí.Caso para mayor claridad.Si necesita columnas como "Nombre", las mayúsculas facilitarán la lectura.

De acuerdo.Ese es mi $0.02

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

Ver Nombre del elemento de datos en Wikipedia:

"Las tablas son colecciones de entidades y siguen las pautas de nomenclatura de colecciones.Lo ideal es utilizar un nombre colectivo:ej., personal.El plural también es correcto:Empleados.Los nombres incorrectos incluyen:Empleado, tblEmployee y EmployeeTable".

Como siempre, hay excepciones a las reglas, p.una tabla que siempre tiene exactamente una fila puede ser mejor con un nombre singular, p.e.una tabla de configuración.Y la coherencia es de suma importancia:compruebe si sus compras tienen una convención y, de ser así, sígala;Si no le gusta, haga un caso de negocios para cambiarlo en lugar de ser el llanero solitario.

nuestra preferencia:

  1. ¿Deben los nombres de las tablas estar en plural?
    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 que la denominación sea innecesariamente complicada.1 casa, 2 casas, ratón contra ratones, persona contra personas, y ni siquiera hemos analizado ningún otro idioma.

    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. ¿Deben los nombres de las columnas ser singulares?
    Por lo general, sí, excepto cuando se infrinjan las reglas de normalización.

  3. ¿Debo anteponer tablas o columnas?
    Principalmente una preferencia de plataforma.Preferimos anteponer las columnas con el nombre de la tabla.No ponemos prefijos en tablas, pero sí en vistas (v_) y procedimientos_almacenados (sp_ o f_ (función)).Eso ayuda a las personas que quieren intentar actualizar 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 excelente manera de evitar la colisión de palabras clave (delivery.from se interrumpe, pero delivery_from no).

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

    bob = new person()
    bob.person_name = 'Bob'
    bob.person_dob = '1958-12-21'
    ...Es muy legible y explícito.Sin embargo, esto puede salirse de control:

    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 ve 'customer_customer_type_id' mientras depura una consulta, sabrá instantáneamente de dónde proviene (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 (!) largo.

  4. ¿Debo utilizar algún caso para nombrar elementos?Sí, minúsculas :), con guiones bajos.Son muy legibles y multiplataforma.Junto con los 3 anteriores también tiene sentido.

    Sin embargo, la mayoría de estas son preferencias.- Siempre y cuando seas coherente, debería ser predecible para cualquiera que tenga que leerlo.

Escucho el argumento todo el tiempo de que si una tabla está pluralizada o no es una cuestión de gusto personal y no existe una mejor práctica.No creo que eso sea cierto, especialmente como programador y no como DBA.Hasta donde yo sé, no hay razones legítimas para pluralizar el nombre de una tabla aparte de "Simplemente tiene sentido para mí porque es una colección de objetos", mientras que existen ganancias legítimas en el código al tener nombres de tabla singulares.Por ejemplo:

  1. Evita errores y errores causados ​​por ambigüedades plurales.Los programadores no son precisamente conocidos por su experiencia en ortografía y pluralizar algunas palabras resulta confuso.Por ejemplo, ¿la palabra plural termina en 'es' o simplemente en 's'?¿Son personas o personas?Cuando trabajas en un proyecto con equipos grandes, esto puede convertirse en un problema.Por ejemplo, un caso en el que un miembro del equipo utiliza el método incorrecto para pluralizar una tabla que crea.En el momento en que interactúo con esta tabla, se utiliza en todo el código al que no tengo acceso o que tardaría mucho en arreglar.El resultado es que tengo que recordar escribir mal la tabla cada vez que la uso.A mí me pasó algo muy parecido a esto.Cuanto más fácil pueda hacer que cada miembro del equipo use de manera consistente y sencilla los nombres de tabla exactos y correctos sin errores o sin tener que buscar nombres de tablas todo el tiempo, mejor.La versión singular es mucho más fácil de manejar en un entorno de equipo.

  2. Si usa la versión singular del nombre de una tabla Y antepone el nombre de la tabla a la clave principal, ahora tiene la ventaja de determinar fácilmente el nombre de una tabla a partir de una clave principal o viceversa solo mediante código.Se le puede proporcionar una variable con un nombre de tabla, concatenar "Id" hasta el final y ahora tendrá la clave principal de la tabla a través del código, sin tener que realizar una consulta adicional.O puede cortar "Id" del final de una clave principal para determinar el nombre de una tabla mediante código.Si utiliza "id" sin un nombre de tabla para la clave principal, entonces no podrá determinar mediante código el nombre de la tabla a partir de la clave principal.Además, la mayoría de las personas que pluralizan los nombres de las tablas y anteponen las columnas PK con el nombre de la tabla usan la versión singular del nombre de la tabla en la PK (por ejemplo, estados y statusId), lo que hace imposible hacer esto en absoluto.

  3. Si hace que los nombres de las tablas sean singulares, puede hacer que coincidan con los nombres de clase que representan.Una vez más, esto puede simplificar el código y permitirle hacer cosas realmente interesantes, como crear una instancia de una clase sin tener nada más que el nombre de la tabla.También hace que su código sea más consistente, lo que lleva a...

  4. Si hace que el nombre de la tabla sea singular, su esquema de nombres será consistente, organizado y fácil de mantener en cada ubicación.Usted sabe que en cada instancia de su código, ya sea en el nombre de una columna, como un nombre de clase o como el nombre de una tabla, es exactamente el mismo nombre.Esto le permite realizar búsquedas globales para ver todos los lugares donde se utilizan los datos.Cuando pluralizas el nombre de una tabla, habrá casos en los que usarás la versión singular de ese nombre de tabla (la clase en la que se convierte, en la clave principal).Simplemente tiene sentido no tener algunos casos en los que se haga referencia a sus datos en plural y otros en singular.

En resumen, si pluraliza los nombres de sus tablas, está perdiendo todo tipo de ventajas para hacer que su código sea más inteligente y más fácil de manejar.Incluso puede haber casos en los que tenga que tener tablas/matrices de búsqueda para convertir los nombres de sus tablas en objetos o nombres de códigos locales que podría haber evitado.Los nombres de tablas en singular, aunque quizás parezcan un poco extraños al principio, ofrecen ventajas significativas sobre los nombres en plural y creo que son las mejores prácticas.

Eche un vistazo a la norma ISO 11179-5:Principios de nombres e identificación Puede obtenerlo aquí: http://metadata-standards.org/11179/#11179-5

Escribí un blog sobre esto hace un tiempo aquí: Convenciones de nomenclatura ISO-11179

Sé que es tarde para el juego y la pregunta ya ha sido respondida muy bien, pero quiero ofrecer mi opinión sobre el punto 3 con respecto al prefijo de los nombres de las columnas.

Todas las columnas deben nombrarse con un prefijo que sea exclusivo de la tabla en la que están definidas.

P.ej.Dadas las tablas "cliente" y "dirección", usemos los prefijos "cust" y "addr", respectivamente."cliente" tendría "cust_id", "cust_name", etc.en eso."address" tendría "addr_id", "addr_cust_id" (FK de vuelta al cliente), "addr_street", etc.en eso.

Cuando me presentaron este estándar por primera vez, estaba totalmente en contra de él;Odiaba la idea.No podía soportar la idea de toda esa mecanografía y redundancia adicionales.Ahora he tenido suficiente experiencia con ello como para no volver nunca más.

El resultado de hacer esto es que todas las columnas del esquema de su base de datos son únicas.Esto tiene un beneficio importante, que supera todos los argumentos en contra (en mi opinión, por supuesto):

Puede buscar en toda su base de código y encontrar de manera confiable cada línea de código que toca una columna en particular.

El beneficio del número 1 es increíblemente enorme.Puedo desaprobar una columna y saber exactamente qué archivos deben actualizarse antes de que la columna pueda eliminarse del esquema de forma segura.Puedo cambiar el significado de una columna y saber exactamente qué código necesita ser refactorizado.O simplemente puedo saber si los datos de una columna se están utilizando en una parte particular del sistema.No puedo contar la cantidad de veces que esto ha convertido un proyecto potencialmente enorme en uno simple, ni la cantidad de horas que hemos ahorrado en el trabajo de desarrollo.

Otro beneficio relativamente menor es que solo tienes que usar alias de tabla cuando realizas una autounión:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

Mis opiniones sobre estos son:

1) No, los nombres de las tablas deben ser singulares.

Si bien parece tener sentido para la selección simple (select * from Orders) tiene menos sentido para el equivalente OO (Orders x = new Orders).

Una tabla en una base de datos es realmente el conjunto de esa entidad, tiene más sentido una vez que usas set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

Esa última línea, la lógica real de la unión, parece confusa con nombres de tablas en plural.

No estoy seguro de usar siempre un alias (como sugiere Matt), lo aclara.

2) Deben ser singulares ya que solo contienen 1 propiedad

3) Nunca, si el nombre de la columna es ambiguo (como arriba donde ambos tienen una columna llamada [Clave]), el nombre de la tabla (o su alias) puede distinguirlos bastante bien.Quiere que las consultas sean rápidas de escribir y sencillas: los prefijos añaden una complejidad innecesaria.

4) Lo que quieras, te sugiero CapitalCase

No creo que exista un conjunto de pautas absolutas para ninguno de estos.

Siempre que lo que elija sea coherente en toda la aplicación o base de datos, no creo que realmente importe.

En mi opinión:

  1. Los nombres de las tablas deben estar en plural.
  2. Los nombres de las columnas deben ser singulares.
  3. No.
  4. Ya sea CamelCase (mi preferido) o underscore_separated tanto para nombres de tablas como de columnas.

Sin embargo, como se ha mencionado, cualquier convención es mejor que ninguna convención.No importa cómo elija hacerlo, documentelo para que futuras modificaciones sigan las mismas convenciones.

  1. Definitivamente mantenga los nombres de las tablas en singular, persona, no personas
    1. Aquí igual
    2. No.He visto algunos prefijos terribles, llegando incluso a indicar que estamos tratando con una tabla (tbl_) o un procedimiento de almacenamiento de usuario (usp_).Esto seguido del nombre de la base de datos...¡No lo hagas!
    3. Sí.Tiendo a PascalCase todos los nombres de mis tablas

Creo que usted y su equipo darían la mejor respuesta a cada una de esas preguntas.Es mucho más importante tener una convención de nomenclatura que cómo es exactamente la convención de nomenclatura.

Como no hay una respuesta correcta para eso, deberías tomarte un tiempo (pero no demasiado) y elegir tus propias convenciones y... aquí está la parte importante: apégate a ello.

Por supuesto, es bueno buscar información sobre los estándares al respecto, que es lo que estás preguntando, pero no te preocupes por la cantidad de respuestas diferentes que puedas obtener:elige el que te parezca mejor.

Por si acaso, aquí están mis respuestas:

  1. Sí.Una mesa es un grupo de registros, profesores o actores, entonces...plural.
  2. Sí.
  3. No los uso.
  4. La base de datos que uso más a menudo, Firebird, mantiene todo en mayúsculas, por lo que no importa.De todos modos, cuando estoy programando escribo los nombres de una manera que sea más fácil de leer, como año de lanzamiento.

Las convenciones de nomenclatura permiten al equipo de desarrollo diseñar la capacidad de descubrimiento y mantenimiento en el centro del proyecto.

Una buena convención de nomenclatura requiere tiempo para evolucionar, pero una vez implementada permite al equipo avanzar con un lenguaje común.Una buena convención de nomenclatura crece orgánicamente con el proyecto.Una buena convención de nomenclatura hace frente fácilmente a los cambios durante la fase más larga e importante del ciclo de vida del software: la gestión de servicios en producción.

Aquí están mis respuestas:

  1. Sí, los nombres de las tablas deben estar en plural cuando se refieren a un conjunto de vientos alisios, valores, o contrapartes Por ejemplo.
  2. Sí.
  3. Sí.Las tablas SQL tienen el prefijo tb_, las vistas tienen el prefijo vw_, los procedimientos almacenados tienen el prefijo usp_ y los activadores tienen el prefijo tg_ seguido del nombre de la base de datos.
  4. El nombre de la columna debe estar en minúsculas separadas por un guión bajo.

Dar nombres es difícil, pero en cada organización hay alguien que puede nombrar cosas y en cada equipo de software debe haber alguien que asuma la responsabilidad de los estándares de nombres y se asegure de que cuestiones de nombres como id_seg, valor_seg y id_seguridad resolverse temprano antes de que se incluyan en el proyecto.

Entonces, ¿cuáles son los principios básicos de una buena convención y estándares de nomenclatura?-

  • Use el idioma de su cliente y su dominio de solución
  • Sea descriptivo
  • Se consistente
  • Desambiguar, reflexionar y refactorizar
  • No use abreviaturas a menos que sean claras para todos
  • No use palabras clave reservadas SQL como nombres de columnas

Aquí hay un enlace que ofrece algunas opciones.Estaba buscando una especificación simple que pudiera seguir en lugar de tener que depender de una parcialmente definida.

http://justinsomnia.org/writings/naming_conventions.html

Los nombres de las tablas siempre deben ser singulares, porque representan un conjunto de objetos.Como se dice rebaño para designar a un grupo de ovejas, o rebaño sí designamos a un grupo de aves.No es necesario el plural.Cuando el nombre de una tabla está compuesto de dos nombres y la convención de nomenclatura está en plural, resulta difícil saber si el nombre en plural debe ser la primera palabra, la segunda o ambas.Es la lógica: Objeto.instancia, no objetos.instancia.O TableName.column, no TableNames.column(s).Microsoft SQL no distingue entre mayúsculas y minúsculas, es más fácil leer los nombres de las tablas, si se utilizan letras mayúsculas, para separar los nombres de las tablas o columnas cuando están compuestos por dos o más nombres.

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

Nombre de la tabla: Debe ser singular, ya que es una entidad singular que representa un objeto del mundo real y no objetos, lo cual es singular.

Nombre de columna: Debe ser singular sólo entonces transmite que tendrá un valor atómico y confirmará la teoría de la normalización.Sin embargo, si hay n números del mismo tipo de propiedades, entonces deben tener el sufijo 1, 2, ..., n, etc.

Prefijos de tablas/columnas:Es un tema enorme, lo discutiremos más adelante.

Caja:Debería ser el caso Camel

Mi amigo, Patricio Karcher, Le pido que no escriba nada que pueda resultar ofensivo para alguien, como escribió: "Además, las claves externas deben nombrarse de manera consistente en diferentes tablas.Debería ser legal golpear a alguien que no hace esto".Nunca he cometido este error, amigo Patrick, pero escribo en general.¿Qué pasa si juntos planean golpearte por esto?:)

Llegué muy tarde a la fiesta, pero todavía quería agregar mi granito de arena sobre los prefijos de columna.

Parece haber dos argumentos principales para usar el estándar de nomenclatura table_column (o tableColumn) para las columnas, ambos basados ​​en el hecho de que el nombre de la columna en sí será único en toda la base de datos:

1) No es necesario que especifique nombres de tablas y/o alias de columnas en sus consultas todo el tiempo.

2) Puede buscar fácilmente en todo el código el nombre de la columna

Creo que ambos argumentos son erróneos.La solución para ambos problemas sin utilizar prefijos es sencilla.Aquí está mi propuesta:

Utilice siempre el nombre de la tabla en su SQL.Por ejemplo, utilice siempre tabla.columna en lugar de columna.

Obviamente resuelve 2), ya que ahora puede buscar table.column en lugar de table_column.

Pero puedo oírte gritar, ¿cómo se resuelve 1)?Se trataba exactamente de evitar esto.Sí, lo fue, pero la solución fue terriblemente defectuosa.¿Por qué?Bueno, la solución del prefijo se reduce a:
Para evitar tener que especificar tabla.columna cuando hay ambigüedad, ¡nombra todas tus columnas tabla_columna!
Pero esto significa que de ahora en adelante SIEMPRE tendrá que escribir el nombre de la columna cada vez que especifique una columna.Pero si tienes que hacer eso de todos modos, ¿cuál es el beneficio de escribir siempre explícitamente table.column?Exacto, no hay ningún beneficio, es exactamente la misma cantidad de caracteres para escribir.

editar:Sí, soy consciente de que nombrar las columnas con el prefijo impone el uso correcto, mientras que mi enfoque depende de los programadores.

Convenciones esenciales de nomenclatura de bases de datos (y estilo) (haga clic aquí para obtener una descripción más detallada)

Los nombres de la tabla eligen nombres cortos e inequívocos, que no se distinguen a más de una o dos palabras, facilita fácilmente el nombre de nombres de campo únicos, así como tablas de búsqueda y vinculación, dan tablas singulares, nunca plural (actualizar::Todavía estoy de acuerdo con las razones dadas para esta convención, pero a la mayoría de la gente realmente le gustan los nombres de tablas en plural, así que he suavizado mi postura)...siga el enlace de arriba por favor

Nombres de tablas en singular.Digamos que estás modelando una relación entre alguien y su dirección.Por ejemplo, si está leyendo un DataModel, preferiría 'cada persona puede vivir a 0,1 o muchas direcciones'. o "cada gente puede vivir a 0,1 o muchas direcciones". Creo que es más fácil pluralizar la dirección, en lugar de tener que reformular a las personas como persona.Además, los sustantivos colectivos suelen ser diferentes a la versión singular. 


--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Estas son las convenciones que me enseñaron, pero debes adaptarte a lo que sea que uses en tu desarrollo.

  1. Plural.Es una colección de entidades.
  2. Sí.El atributo es una representación de la propiedad singular de una entidad.
  3. Sí, el nombre de la tabla de prefijos permite nombrar fácilmente todos los índices de restricciones y alias de tablas.
  4. Pascal Case para nombres de tablas y columnas, prefijo + TODAS las mayúsculas para índices y restricciones.
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top