Convenciones de nombres 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. ¿Deben los nombres de las tablas ser plurales?
2. ¿Deben los nombres de columna ser singulares?
3. ¿Debo prefijar tablas o columnas?
4. ¿Debo usar algún caso para nombrar elementos?

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

Recomiendo consultar las bases de datos de ejemplo de Microsoft SQL Server: 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 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. Carcasa Pascal (también conocida como caja de camello superior)

Respuesta tardía aquí, pero en resumen:

1. Mi preferencia es plural
2. si
3. Tablas : * Generalmente * sin prefijos es mejor. Columnas : No.
4. Tanto tablas como columnas: PascalCase.

Elaboración:

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

• Nombre sus claves primarias usando el formato "[singularOfTableName] ID". Es decir, ya sea que el nombre de su tabla sea Cliente o Clientes , la clave principal debe ser CustomerID .
• Además, las claves foráneas deben nombrarse consistentemente en diferentes tablas. Debería ser legal golpear a alguien que no hace esto. Diría que si bien las restricciones de clave externa definidas a menudo son importantes, la denominación constante de clave externa siempre es importante
• Su base de datos debe tener convenciones internas . Aunque en las secciones posteriores me verá muy flexible, dentro de una base de datos, los nombres deben ser muy consistentes. 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 puede lanzar una moneda para determinar cómo usar guiones bajos, pero luego debe 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.

• Los campos que representan el mismo tipo de datos en diferentes tablas deben llamarse iguales. No tenga 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 divertido. Me ocuparé de 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 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 más salvajes. Cus_AddRef. ¿Que demonios es eso? ¿Referencia de destinatario de custodia? ¿Reembolso adicional del cliente? ¿Referencia de dirección personalizada?

(3) Lo que debes considerar.

• Realmente creo que deberías tener nombres plurales para tablas; Algunos piensan en singular. Lee los argumentos en otra parte. Sin embargo, los nombres de columna 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 tiene una tabla de Promociones y Artículos , una tabla que representa un artículo que forma parte de una promoción podría ser Promotions_Items, pero también podría ser legítimamente Promotion_Items, creo (reflejando la relación uno a muchos).
• Use guiones bajos consistentemente y para un propósito particular. Solo los nombres de tablas generales deben ser lo suficientemente claros con PascalCasing; No necesita guiones bajos para separar las palabras. Guarde los guiones bajos (a) para indicar una tabla asociativa o (b) para el prefijo, que abordaré en la próxima viñeta.
• Los prefijos no son buenos ni malos. Por lo general, 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 sin ajustarse a sus categorías fácilmente, y en realidad puede hacer que sea más difícil encontrar tablas. Con experiencia, puede planificar y aplicar un esquema de prefijos que hace más bien que mal. Una vez trabajé en una base de datos donde las tablas de datos comenzaron con tbl , las tablas de configuración con ctbl , las vistas con vew , sp de proc y fn de udfy algunos otros; fue meticulosamente aplicado de manera 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 el mismo db; Su prefijo puede ser muy útil para agrupar las tablas. El prefijo también está bien para situaciones especiales, como las tablas temporales que desea destacar.
• Muy raramente (si alguna vez) le gustaría prefijar columnas.

Ok, ya que estamos evaluando nuestra opinión:

Creo que los nombres de las tablas deberían 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. Por lo tanto, llamaría a una tabla de Entidades Personales Personas (o Personas, lo que sea que te apetezca).

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

SELECT person.Name
FROM People person

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

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

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

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

Usamos nombres singulares para las tablas. Las tablas tienden a tener como prefijo 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" número ", _dt para" Fecha ").

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

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 entidad preferidos, prefijos y siglas y que entregue este documento a sus desarrolladores. Luego, cuando deciden crear una nueva tabla, pueden consultar el documento en lugar de "adivinar" cómo deben llamarse la tabla y los campos.

1. No. Una tabla debe tener el nombre de la entidad que representa. Persona, no personas es cómo se referiría a quien sea que represente 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. Si. En caso de claridad. Si necesita tener columnas como "Nombre", la carcasa facilitará la lectura.

Okay. Esa 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 ser prescriptivas.

Ver Nombre del elemento de datos en Wikipedia :

"Las tablas son colecciones de entidades y siguen las pautas de denominación de colecciones. Idealmente, se usa un nombre colectivo: por ejemplo, personal. El plural también es correcto: empleados. Los nombres incorrectos incluyen: empleado, tblEmployee y EmployeeTable".

Como siempre, hay excepciones a las reglas, por ejemplo, una tabla que siempre tiene exactamente una fila puede ser mejor con un nombre singular, por ejemplo, una tabla de configuración. Y la consistencia es de suma importancia: verifique si su tienda tiene 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.

Escucho el argumento todo el tiempo de que si una tabla está pluralizada o no es una cuestión de gusto personal y no hay una mejor práctica. No creo que eso sea cierto, especialmente como programador en lugar de un DBA. Hasta donde sé, no hay razones legítimas para pluralizar un nombre de tabla que no sea "Simplemente tiene sentido para mí porque es una colección de objetos", mientras que hay 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 exactamente conocidos por su experiencia en ortografía, y la pluralización de algunas palabras es confusa. Por ejemplo, ¿la palabra plural termina en 'es' o simplemente 's'? ¿Son personas o personas? Cuando trabajas en un proyecto con equipos grandes, esto puede convertirse en un problema. Por ejemplo, una instancia en la que un miembro del equipo usa el método incorrecto para pluralizar una tabla que crea. En el momento en que interactúo con esta tabla, se usa en todo el código al que no tengo acceso o que tardaría demasiado en solucionarlo. El resultado es que debo recordar escribir mal la tabla cada vez que la uso. Algo muy similar a esto me sucedió. Cuanto más fácil sea hacer que todos los miembros del equipo usen de manera consistente y sencilla la información exacta, nombres de tabla correctos sin errores o tener que buscar nombres de tabla 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 de un nombre de tabla Y el prefijo de la clave primaria con el nombre de la tabla, ahora tiene la ventaja de determinar fácilmente el nombre de una tabla a partir de una clave primaria o viceversa a través del código solo. Se le puede dar una variable con un nombre de tabla, concatenar "Id" hasta el final, y ahora tiene la clave principal de la tabla a través del código, sin tener que hacer una consulta adicional. O puede cortar "Id" desde el final de una clave primaria para determinar el nombre de una tabla a través del código. Si usa "id" sin un nombre de tabla para la clave primaria, entonces no puede determinar mediante el código el nombre de la tabla a partir de la clave primaria. Además, la mayoría de las personas que pluralizan los nombres de las tablas y prefijan las columnas PK con el nombre de la tabla usan la versión singular del nombre de la tabla en la PK (por ejemplo, status y status_id),

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 ordenadas, como crear una instancia de una clase teniendo solo el nombre de la tabla. También hace que su código sea más consistente, lo que conduce a ...

4. Si hace que el nombre de la tabla sea singular, hace que su esquema de nombres sea 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 el nombre de una clase o como el nombre de la tabla, es el mismo nombre exacto. Esto le permite realizar búsquedas globales para ver en todas partes que se utilizan datos. Cuando pluraliza el nombre de una tabla, habrá casos en los que utilizará la versión singular de ese nombre de tabla (la clase en la que se convierte, en la clave primaria). Simplemente tiene sentido no tener algunas instancias en las que se hace referencia a sus datos como plural y algunas instancias singulares.

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

nuestra preferencia:

1. ¿Deben los nombres de las tablas ser plurales?
   Nunca. Los argumentos para que sea una colección tienen sentido, pero nunca se sabe qué va a contener 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 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. ¿Deben los nombres de columna ser singulares?
   Por lo general, sí, excepto cuando está rompiendo las reglas de normalización.

3. ¿Debo prefijar tablas o columnas?
   Principalmente una preferencia de plataforma. Preferimos prefijar columnas con el nombre de la tabla. No prefijamos tablas, pero sí prefijamos vistas (v_) y procedimientos almacenados (sp_ o f_ (función)). Eso ayuda a las personas que desean intentar actualizar v_person.age, que en realidad es un campo calculado en una vista (que de todos modos no se puede ACTUALIZAR).

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

   Sí hace que el código sea más detallado, pero a menudo ayuda a 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, sabe instantáneamente de dónde proviene (tabla de clientes).

   o donde tiene una relación MM entre customer_type y customer_category (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 algún caso para nombrar elementos? Sí, minúscula :), con guiones bajos. Estos son muy legibles y multiplataforma. Junto con 3 arriba también tiene sentido.

   Sin embargo, la mayoría de estos son preferencias. - Siempre y cuando sea coherente, debe ser predecible para cualquiera que tenga que leerlo.

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

Hace un blog lo escribí aquí: Convenciones de nomenclatura ISO-11179

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

Todas las columnas deben nombrarse con un prefijo que sea único para la tabla en la que se definen.

Por ejemplo, en las tablas "cliente" y "dirección", vamos con los prefijos de "cust" y "addr", respectivamente. "cliente" tendría "cust_id", "cust_name", etc. en él. "dirección" tendría "addr_id", "addr_cust_id" (FK de regreso al cliente), "addr_street", etc.

Cuando se me presentó por primera vez este estándar, estaba totalmente en contra de él; Odiaba la idea. No podía soportar la idea de todo ese tipeo y redundancia adicionales. Ahora tengo suficiente experiencia con eso que nunca volvería.

El resultado de hacer esto es que todas las columnas en el esquema de su base de datos son únicas. Hay un beneficio importante para esto, que supera todos los argumentos en su 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 toque una columna en particular.

El beneficio del # 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 decir si los datos de una columna incluso 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 tiene que usar alias de tabla cuando realiza 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 está utilizando 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 plurales.

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

2) Deben ser singulares ya que solo tienen 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 lo suficientemente bien. Desea que las consultas sean rápidas de escribir y simples: los prefijos agregan complejidad innecesaria.

4) Lo que quieras, te sugiero CapitalCase

No creo que haya un conjunto de pautas absolutas sobre ninguno de estos.

Mientras lo que elija sea consistente en la aplicación o en la base de datos, no creo que realmente importe.

En mi opinión:

1. Los nombres de las tablas deben ser plurales.
2. Los nombres de columna deben ser singulares.
3. No.
4. CamelCase (mi preferido) o subrayado_separado para los nombres de tabla y columna.

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

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 la convención de nomenclatura.

Como no hay una respuesta correcta a eso, debe tomarse un tiempo (pero no demasiado) y elegir sus propias convenciones y, aquí está la parte importante, atenerse a ellas.

Por supuesto, es bueno buscar información sobre los estándares sobre eso, que es lo que está preguntando, pero no se preocupe ni se preocupe por la cantidad de respuestas diferentes que puede obtener: elija la que le parezca mejor.

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

1. Si. Una tabla es un grupo de registros , maestros o actores , así que ... plural.
2. Si.
3. No los uso
4. La base de datos que uso con más frecuencia, Firebird, mantiene todo en mayúsculas, por lo que no importa. De todos modos, cuando estoy programando escribo los nombres de manera que sea más fácil de leer, como releaseYear .

1. Definitivamente mantenga los nombres de las tablas en singular, persona no personas
   2. Igual que aquí
   3. No. He visto algunos prefijos terribles, llegando al extremo de indicar con qué se trata una tabla (tbl_) o un procedimiento de almacenamiento de usuario (usp_). Esto seguido por el nombre de la base de datos ... ¡No lo hagas!
   4. Si. Tiendo a PascalCase todos los nombres de mi tabla

Las convenciones de nomenclatura permiten al equipo de desarrollo diseñar capacidad de descubrimiento y mantenibilidad en el corazón del proyecto.

Una buena convención de nombres lleva tiempo para evolucionar, pero una vez que está en su lugar, permite que el equipo avance con un lenguaje común. Una buena convención de nombres 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 del servicio en la 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 operaciones , valores o contrapartes, por ejemplo.
2. Si.
3. Si. Las tablas SQL tienen el prefijo tb_, las vistas tienen el prefijo vw_, los procedimientos almacenados tienen el prefijo usp_ y los desencadenantes tienen el prefijo tg_ seguido del nombre de la base de datos.
4. El nombre de la columna debe estar en minúsculas, separado por un guión bajo.

Nombrar es difícil, pero en cada organización hay alguien que puede nombrar cosas y en cada equipo de software debe haber alguien que se responsabilice de los estándares de nomenclatura y se asegure de que los problemas de nomenclatura como sec_id , sec_value y security_id se resuelvan temprano antes de integrarse en el proyecto. .

¿Cuáles son los principios básicos de una buena convención de nombres y estándares?

• Use el idioma de su cliente y su dominio de solución
• Ser descriptivo
• Se consistente
• Desambigua, reflexiona y refactoriza
• No use abreviaturas a menos que sean claras para todos
• No use palabras clave reservadas de SQL como nombres de columna

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

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

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

Los nombres de las tablas siempre deben ser singulares, ya que representan un conjunto de objetos. Como usted dice rebaño para designar un grupo de ovejas, o rebaño designe un grupo de pájaros. No hay necesidad de plural. Cuando un nombre de tabla es una composición de dos nombres y la convención de nomenclatura está en plural, se hace difícil saber si el nombre plural debe ser la primera palabra o la segunda palabra 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 tablas o columnas cuando están compuestos de dos o más nombres.

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

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

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

Carcasa: debe ser un caso Camel

Mi amigo, Patrick Karcher , le pido que no escriba nada que pueda ser ofensivo para alguien, como escribió: "• Además, las claves foráneas deben ser nombradas consistentemente en diferentes tablas. Debería ser legal golpear a alguien que no hacer esto.". Nunca he cometido este error mi amigo Patrick, pero en general estoy escribiendo. ¿Qué pasa si juntos planean golpearte por esto? :)

Muy tarde a la fiesta, pero todavía quería agregar mis dos centavos sobre los prefijos de columna

Parece que hay 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 será único en toda su base de datos:

1) No tiene que especificar nombres de tabla y / o alias de columna 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 defectuosos. La solución para ambos problemas sin usar prefijos es fácil. Aquí está mi propuesta:

Siempre use el nombre de la tabla en su SQL. Por ejemplo, use siempre table.column en lugar de column.

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

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

editar: sí, soy consciente de que nombrar las columnas con el prefijo exige el uso correcto, mientras que mi enfoque se basa en los programadores

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

los nombres de tablas eligen nombres cortos e inequívocos, el uso de no más de una o dos palabras para distinguir tablas facilita fácilmente la denominación de nombres de campo únicos, así como las tablas de búsqueda y vinculación dan a las tablas nombres singulares, nunca plurales (actualización: 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 estabas modelando una relación entre alguien y su dirección. Por ejemplo, si está leyendo un modelo de datos, preferiría que "cada persona pueda vivir con 0,1 o más direcciones". o 'cada persona puede vivir en 0,1 o en muchas direcciones'. Creo que es más fácil pluralizar la dirección, en lugar de tener que reformular a las personas como personas. Además, los sustantivos colectivos a menudo son distintos de 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.

1. Plural. Es una colección de entidades.
2. Si. El atributo es una representación de 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 tabla.
4. Pascal Case para nombres de tabla y columna, prefijo + TODOS mayúsculas para índices y restricciones.