usar una tablas para nomenclatura nombrar los las hora diseñar datos costumbre buena database database-design language-agnostic naming-conventions

database - una - nomenclatura base de datos



¿Bases de datos, tablas y nombres de columnas convenciones? (23)

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 tabla ser plural?
  2. ¿Los nombres de las columnas deberían ser singulares?
  3. ¿Debo prefijo tablas o columnas?
  4. ¿Debo usar algún caso al nombrar elementos?

¿Hay alguna guía recomendada para nombrar elementos en una base de datos?

  1. Definitivamente mantener los nombres de las tablas en singular, persona no personas
    1. Igual que aquí
    2. No. He visto algunos prefijos terribles, llegando a afirmar que se trataba de una tabla (tbl_) o un procedimiento de almacenamiento de usuario (usp_). Esto seguido por el nombre de la base de datos ... ¡No lo hagas!
    3. Sí. Tiendo a PascalCase todos los nombres de mis tablas.
  1. No. Una tabla debe tener el nombre de la entidad que representa. Persona, no personas es cómo se referiría a quien represente uno de los registros.
  2. De nuevo, lo mismo. La columna Nombre de pila realmente no debería llamarse Primeros nombres. Todo depende de lo que quieras representar con la columna.
  3. NO.
  4. Sí. Caso que sea por claridad. Si necesita tener columnas como "Nombre", la carcasa hará que sea más fácil de leer.

De acuerdo. Eso es mi $ 0.02

Tabla de nombres singulares. 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 a 0,1 o varias direcciones''. o ''cada pueblo puede vivir en 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 a menudo son distintos de la versión singular.

Creo que usted y su equipo darán la mejor respuesta a cada una de esas preguntas. Es mucho más importante tener una convención de denominación que la convención de denominación.

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

Por supuesto, es bueno buscar información acerca de los estándares sobre eso, que es lo que está preguntando, pero no se preocupe ni 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. Sí. Una mesa es un grupo de registros , maestros o actores , así que ... plural.
  2. Sí.
  3. Yo 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 una manera que es más fácil de leer, como liberar el año .

En mi opinión:

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

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

Escucho el argumento todo el tiempo de que si una tabla está o no pluralizada 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. Por lo que yo 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 habilidad para deletrear, 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 grandes equipos, esto puede convertirse en un problema. Por ejemplo, una instancia en la 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 que no tengo acceso o que tardaría mucho en solucionar. El resultado es que tengo que acordarme de escribir mal la tabla cada vez que la uso. Algo muy similar a esto me sucedió. Cuanto más fácil sea para cada miembro del equipo usar los nombres de tabla exactos y correctos de forma consistente y sin errores o 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 de un nombre de tabla Y el prefijo de la clave primaria con el nombre de la tabla, ahora tiene la ventaja de que puede determinar fácilmente el nombre de una tabla a partir de una clave principal o viceversa solo a través del código. 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 principal para determinar el nombre de una tabla a través del código. Si usa "id" sin un nombre de tabla para la clave principal, entonces no puede, a través del código, determinar 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 las columnas con el prefijo PK con el nombre de la tabla usan la versión singular del nombre de la tabla en la PK (por ejemplo, statuses y statusId), lo que hace que sea imposible hacerlo.

  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 permitirte hacer cosas realmente claras, como crear una instancia de una clase al no tener 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, 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 un nombre de columna, como nombre de clase o como nombre de tabla, es el mismo nombre exacto. Esto le permite hacer búsquedas globales para ver en cualquier lugar donde se usan los datos. Cuando pluraliza un nombre de tabla, habrá casos en los que usará 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 algunas instancias en las que se hace referencia a sus datos como plural y algunas instancias en singular.

En resumen, si pluraliza los nombres de sus tablas, está perdiendo todo tipo de ventajas al hacer que su código sea más inteligente y fácil de manejar. Incluso puede haber casos en los que tenga que buscar tablas / matrices para convertir los nombres de sus tablas en nombres de objetos o códigos locales que podría haber evitado. Los nombres de las 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.

Las convenciones de nomenclatura permiten que el equipo de desarrollo diseñe la capacidad de descubrimiento y mantenimiento en el corazón del proyecto.

Una buena convención de nomenclatura toma tiempo para evolucionar, pero una vez que está en su lugar, le 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 del servicio en producción.

Aquí están mis respuestas:

  1. Sí, los nombres de las tablas deben ser plurales cuando se refieren a un conjunto de operaciones , valores o contrapartes, por ejemplo.
  2. Sí.
  3. Sí. Las tablas de 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úscula separado por un guión bajo.

Nombrar es difícil, pero en cada organización hay alguien que puede nombrar las cosas y en cada equipo de software debe haber alguien que asuma la responsabilidad de los estándares de denominación y se asegure de que los problemas de denominación como sec_id , sec_value y security_id se resuelvan antes de que se incorporen al proyecto. .

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

  • Usa el idioma de tu cliente y el dominio de tu solución.
  • Ser descriptivo
  • Se consistente
  • Desambiguar, reflexionar y refactorizar.
  • No uses abreviaturas a menos que sean claras para todos.
  • No utilice palabras clave reservadas de SQL como nombres de columna

Los nombres de las tablas siempre deben ser singulares, ya que representan un conjunto de objetos. Como usted dice manada para designar un grupo de ovejas, o rebaño designar un grupo de aves. No hay necesidad de plural. Cuando el nombre de una tabla está compuesto por dos nombres y la convención de nomenclatura está en plural, resulta difícil saber si el nombre plural debe ser la primera palabra o la segunda palabra o ambas. Es la lógica - Object.instance, no objects.instance. 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 se componen de dos o más nombres.

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 de 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és usando set-logic:

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

La ú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 sugiere Matt) lo aclara.

2) Deben ser singulares ya que solo tienen 1 propiedad.

3) Nunca, si el nombre de la columna es ambiguo (como anteriormente, 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 una complejidad innecesaria.

4) Lo que quieras, te sugiero CapitalCase

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

Siempre que lo que elija sea consistente en toda la aplicación o DB, no creo que realmente importe.

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

Parece que hay dos argumentos principales para utilizar el estándar de denominación 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 su base de datos:

1) No tiene que especificar nombres de tablas y / o alias de columnas en sus consultas todo el tiempo

2) Puedes buscar fácilmente en tu código completo el nombre de la columna

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

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

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

Pero puedo oírte gritar, ¿cómo resuelve 1)? Era exactamente sobre evitar esto. Sí, lo fue, pero la solución fue horriblemente defectuosa. ¿Por qué? Bueno, la solución de prefijo se reduce a:
Para evitar tener que especificar table.column cuando hay ambigüedad, ¡debes nombrar todas tus columnas table_column!
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 tiene que hacer eso de todos modos, ¿cuál es el beneficio de escribir siempre table.column explícitamente? Exactamente, no hay beneficio, es el mismo número exacto de caracteres que escribir.

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

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 llamaría a una tabla de Personas de Personas (o Personas, lo que sea más atractivo para usted).

Para aquellos a los que les gusta ver "nombres de entidades" singulares en las consultas, eso es para lo que usaría los alias de tablas para:

SELECT person.Name FROM People person

Un poco como LINQ "de person in people select person.Name".

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

Recomiendo revisar las bases de datos de muestra 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 (Ej .: SchemeName.TableName)
  4. Casquillo de Pascal (también conocido como funda de camello superior)

Respuesta tardía aquí, pero en definitiva:

  1. Mi preferencia es plural
  2. Sí
  3. Tablas : * Generalmente * sin prefijos es mejor. Columnas : No.
  4. Ambas tablas y columnas: PascalCase.

Elaboración:

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

  • Nombre sus claves primarias utilizando 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 externas deben nombrarse de manera consistente 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 importantes, la denominación de clave externa consistente siempre es importante
  • Su base de datos debe tener convenciones internas . Aunque en las secciones posteriores verá que soy muy flexible, dentro de una base de datos, la denominación debe ser muy coherente. Si su mesa para clientes se llama Clientes o Clientes es menos importante que hacerlo de la misma manera en la misma base de datos. Y puedes lanzar una moneda para determinar cómo usar guiones bajos, pero luego debes 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 tener el mismo nombre. No tenga Zip en una tabla y ZipCode en otra.
  • Para separar palabras en sus nombres de 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 gracioso. Abordaré los guiones bajos en un momento. (Es posible que no use ALLCAPS como en los días anteriores. OBNOXIOUSTABLE.ANNOYING_COLUMN estuvo bien en DB2 hace 20 años, pero no ahora).
  • No acortar o abreviar artificialmente las palabras. Es mejor que un nombre sea largo y claro que corto y confuso. Los nombres ultra cortos son un remanente de tiempos más oscuros, más salvajes. Cus_AddRef. ¿Que demonios es eso? ¿Custodial destinatario de referencia? ¿Reembolso adicional al cliente? ¿Referencia de dirección personalizada?

(3) Lo que debes considerar.

  • Realmente creo que deberías tener nombres plurales para las tablas; algunos piensan en singular. Lee los argumentos en otra parte. Sin embargo, los nombres de las columnas deben ser singulares. Incluso si usa nombres de tablas plurales, 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 Artículos de Promociones, pero también podría ser legítimamente Artículos de Promoción (que refleja la relación uno a varios).
  • Use guiones bajos de manera consistente y para un propósito particular. Solo los nombres de las tablas generales deben ser lo suficientemente claros con PascalCasing; No necesitas 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 siguiente viñeta.
  • El prefijo no es ni bueno ni malo. Por lo general 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 no se ajustan fácilmente a sus categorías, y en realidad puede hacer que sea más difícil encontrar tablas. Con experiencia, puede planificar y aplicar un esquema de prefijo que haga más bien que mal. Trabajé en una base de datos una vez donde las tablas de datos comenzaron con tbl , las tablas de configuración con ctbl , las vistas con vew , proc''s sp , y ff de udf, y algunas otras; Fue meticulosamente, se aplicó de manera consistente, así que funcionó bien. La única vez que NECESITA prefijos es cuando realmente tiene soluciones separadas que, por alguna razón, residen en la misma db; prefijarlos puede ser muy útil para agrupar las tablas. El prefijo también está bien para situaciones especiales, como para las tablas temporales que desea destacar.
  • Muy rara vez (si alguna) desea prefijar columnas.

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 las columnas.

Todas las columnas deben nombrarse con un prefijo que sea único para la tabla en la que están definidas.

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

Cuando me presentaron esta norma por primera vez, estaba totalmente en contra; Odiaba la idea. No podía soportar la idea de toda esa escritura extra y redundancia. Ahora he tenido suficiente experiencia con él que nunca regresaría.

El resultado de hacer esto es que todas las columnas en su esquema de 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 toca 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 se pueda eliminar de forma segura del esquema. Puedo cambiar el significado de una columna y saber exactamente qué código debe ser refactorizado. O simplemente puedo decir si los datos de una columna se están utilizando en una parte específica 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 tablas cuando realizas una unión automática:

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%'';

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

Ver nombre del elemento de datos en Wikipedia :

"Las tablas son colecciones de entidades y siguen las pautas de nomenclatura de colecciones. Idealmente, se usa un nombre colectivo: por ejemplo, Personal. La plural también es correcta: 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, si es así, sígala; Si no te gusta, haz un caso de negocios para cambiarlo en lugar de ser el guardabosques solitario.

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 existe un estándar "único", todos tenemos nuestras preferencias
  3. Si ya existe un estándar, utilícelo. No cree otro estándar o enturbie los estándares existentes.

Usamos nombres singulares para las tablas. Las tablas tienden a ser prefijadas con el nombre del sistema (o su acrónimo). Esto es útil si el sistema 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, esperamos 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 la PK, _cd para "código", _nm para "nombre ", _nb para" número ", _dt para" Fecha ").

El nombre del campo clave de Foriegn debe ser el mismo que el 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 de entidades, prefijos y acrónimos 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 deben llamarse la tabla y los campos.

nuestra preferencia:

  1. ¿Deben los nombres de tabla ser plural?
    Nunca. Los argumentos para que sea una colección tienen sentido, pero nunca se sabe lo que contendrá la tabla (0,1 o muchos elementos). Las reglas plurales hacen que el nombramiento sea innecesariamente complicado. 1 casa, 2 casas, ratón contra ratón, persona contra persona, y ni siquiera hemos visto otros idiomas.

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

  2. ¿Los nombres de las columnas deberían ser singulares?
    Por lo general, sí, excepto cuando se rompen las reglas de normalización.

  3. ¿Debo prefijo tablas o columnas?
    Sobre todo una preferencia de plataforma. Preferimos prefijar columnas con el nombre de la tabla. No prefijamos las tablas, pero hacemos vistas de prefijo (v_) y storage_procedures (sp_ o f_ (function)). 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 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ícita. Esto puede salir de las manos 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 ve ''customer_customer_type_id'' mientras depura una consulta, sabrá de inmediato de dónde proviene (tabla del cliente).

    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 al 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 estas son preferencias. - Mientras sea consistente, debería ser predecible para cualquier persona que tenga que leerlo.

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

los nombres de las tablas eligen nombres cortos y no ambiguos, el uso de no más de una o dos palabras distingue las tablas facilita la asignación de nombres de campos únicos, así como las tablas de búsqueda y vinculación dan a las tablas nombres singulares, nunca en plural (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

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 la columna: Solo debe ser singular, entonces transmite que mantendrá un valor atómico y confirmará la teoría de la normalización. Sin embargo, si hay un número n del mismo tipo de propiedades, entonces deben tener el sufijo 1, 2, ..., n, etc.

Prefijando Tablas / Columnas: Es un tema enorme, lo discutiremos más adelante.

Carcasa: Debería ser de funda camel.

Mi amigo, Patrick Karcher , le pido que no escriba nada que pueda ser ofensivo para alguien, como usted escribió: "Además, las claves externas deben nombrarse de manera consistente en diferentes tablas. Debe ser legal golpear a alguien que no lo hace hacer esto.". Nunca he cometido este error, mi amigo Patrick, pero en general estoy escribiendo. ¿Y si juntos planean vencerte por esto? :)

--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 para mangueras de 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 una asignación fácil de nombres de todos los índices de restricciones y alias de tablas.
  4. Pascal Case para nombres de tablas y columnas, prefijo + TODOS los límites para los índices y restricciones.

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