Nombre de la tabla
recientemente aprendido singular es correcto
Si. Cuidado con los paganos. Plural en los nombres de las tablas. son un signo seguro de alguien que no ha leído ninguno de los materiales estándar y no tiene conocimiento de la teoría de bases de datos.
Algunas de las cosas maravillosas sobre los estándares son:
- todos están integrados entre sí
- trabajan juntos
- fueron escritos por mentes más grandes que la nuestra, por lo que no tenemos que debatirlos.
El nombre de la tabla estándar se refiere a cada fila de la tabla, que se usa en todos los verbos, no el contenido total de la tabla (sabemos que la Customer
tabla contiene todos los Clientes).
Relación, frase verbal
En las bases de datos relacionales genuinas que se han modelado (a diferencia de los sistemas de archivo de registros anteriores a 1970 [caracterizados porque Record IDs
se implementan en un contenedor de base de datos SQL por conveniencia):
- las tablas son los Sujetos de la base de datos, por lo tanto son sustantivos , nuevamente, singulares
- las relaciones entre las tablas son las acciones que tienen lugar entre los sustantivos, por lo tanto, son verbos (es decir, no están numerados ni nombrados arbitrariamente)
- ese es el predicado
- todo lo que se puede leer directamente del modelo de datos (consulte mis ejemplos al final)
- (el predicado para una tabla independiente (el principal superior en una jerarquía) es que es independiente)
- así, la Frase verbal se elige cuidadosamente, de modo que sea la más significativa, y se evitan los términos genéricos (esto se hace más fácil con la experiencia). La frase verbal es importante durante el modelado porque ayuda a resolver el modelo, es decir. aclarando relaciones, identificando errores y corrigiendo los nombres de las tablas.
Diagrama_A
Por supuesto, la relación se implementa en SQL como CONSTRAINT FOREIGN KEY
en la tabla secundaria (más, más adelante). Aquí está la frase verbal (en el modelo), el predicado que representa (para leer del modelo) y el nombre de restricción FK :
Initiates
Each Customer Initiates 0-to-n SalesOrders
Customer_Initiates_SalesOrder_fk
Tabla • Idioma
Sin embargo, cuando describa la tabla, particularmente en lenguaje técnico como los predicados u otra documentación, use el singular y el plural tal como están en el idioma inglés. Teniendo en cuenta que la tabla se nombra para la fila única (relación) y el lenguaje se refiere a cada fila derivada (relación derivada):
Each Customer initiates zero-to-many SalesOrders
no
Customers have zero-to-many SalesOrders
Entonces, si obtuve una tabla "usuario" y luego obtuve productos que solo el usuario tendrá, ¿la tabla debería llamarse "usuario-producto" o simplemente "producto"? Esta es una relación de uno a muchos.
(Esa no es una pregunta de convención de nomenclatura; esa es una pregunta de diseño de db.) No importa si user::product
es 1 :: n. Lo que importa es si product
es una entidad separada y si es una tabla independiente , es decir. Puede existir por sí mismo. Por lo tanto product
no user_product
.
Y si product
existe solo en el contexto de un user
, es decir. es una tabla dependiente , por lo tanto user_product
.
Diagrama_B
Y más adelante, si tuviera (por alguna razón) varias descripciones de productos para cada producto, ¿sería "descripción de producto de usuario" o "descripción de producto" o simplemente "descripción"? Por supuesto, con las claves foráneas correctas establecidas. Nombrar solo la descripción sería problemático ya que también podría tener una descripción de usuario o una descripción de cuenta o lo que sea.
Así es. De cualquier user_product_description
XOR product_description
será correcta, sobre la base de lo anterior. No es para diferenciarlo de otro xxxx_descriptions
, sino para darle al nombre una idea de dónde pertenece, siendo el prefijo la tabla principal.
¿Qué pasa si quiero una tabla relacional pura (muchas a muchas) con solo dos columnas, ¿cómo sería? "user-stuff" o tal vez algo como "rel-user-stuff"? Y si es el primero, ¿qué distinguiría esto de, por ejemplo, "producto de usuario"?
Afortunadamente, todas las tablas en la base de datos relacional son tablas puramente relacionales y normalizadas. No es necesario identificar eso en el nombre (de lo contrario, todas las tablas estarán rel_something
).
Si contiene solo las PK de los dos padres (que resuelve la relación lógica n :: n que no existe como entidad en el nivel lógico, en una tabla física ), esa es una Tabla asociativa . Sí, normalmente el nombre es una combinación de los dos nombres de la tabla principal.
Tenga en cuenta que en estos casos la Frase verbal se aplica y se lee de padres a padres, ignorando la tabla secundaria, porque su único propósito en la vida es relacionar a los dos padres.
Diagrama_C
Si es no una tabla asociativa (es decir., Además de los dos PKs, contiene datos), a continuación, nombre apropiadamente, y las frases verbales se aplican a la misma, no el padre al final de la relación.
Diagrama_D
Si termina con dos user_product
tablas, es una señal muy fuerte de que no ha normalizado los datos. Así que retroceda unos pasos y haga eso, y nombre las tablas con precisión y coherencia. Los nombres se resolverán por sí mismos.
Convenio de denominación
Cualquier ayuda es muy apreciada y si hay algún tipo de convención de nomenclatura estándar que ustedes recomienden, no duden en vincular.
Lo que está haciendo es muy importante y afectará la facilidad de uso y comprensión en todos los niveles. Por lo tanto, es bueno obtener la mayor comprensión posible desde el principio. La relevancia de la mayoría de esto no será clara, hasta que comience a codificar en SQL.
El caso es el primer elemento a tratar. Todas las mayúsculas son inaceptables. El caso mixto es normal, especialmente si los usuarios pueden acceder directamente a las tablas. Consulte mis modelos de datos. Tenga en cuenta que cuando el buscador está utilizando un NonSQL demente, que solo tiene minúsculas, le doy eso, en cuyo caso incluyo guiones bajos (según sus ejemplos).
Mantener un enfoque de datos , no una aplicación o enfoque de uso. Es, después de todo 2011, hemos tenido Arquitectura Abierta desde 1984, y se supone que las bases de datos son independientes de las aplicaciones que las usan.
De esa manera, a medida que crecen, y más de lo que las usa una aplicación, los nombres seguirán siendo significativos y no necesitarán corrección. (Las bases de datos que están completamente integradas en una sola aplicación no son bases de datos). Nombra los elementos de datos solo como datos.
Sea muy considerado y nombre las tablas y columnas con mucha precisión . No lo use UpdatedDate
si es un DATETIME
tipo de datos, úselo UpdatedDtm
. No lo use _description
si contiene una dosis.
Es importante ser coherente en toda la base de datos. No lo use NumProduct
en un lugar para indicar la cantidad de Productos ItemNo
ni ItemNum
en otro lugar para indicar la cantidad de Artículos. Úselo NumSomething
para números de, y / SomethingNo
o SomethingId
para identificadores, consistentemente.
No prefije el nombre de la columna con un nombre de tabla o código corto, como user_first_name
. SQL ya proporciona el nombre de la tabla como calificador:
table_name.column_name -- notice the dot
Excepciones:
La primera excepción es para las PK, necesitan un manejo especial porque las codifica en combinaciones todo el tiempo y desea que las claves se destaquen de las columnas de datos. Siempre use user_id
, nunca id
.
- Tenga en cuenta que este no es un nombre de tabla utilizado como prefijo, sino un nombre descriptivo adecuado para el componente de la clave:
user_id
es la columna que identifica a un usuario, no el nombre id
deluser
tabla.
- (Excepto, por supuesto, en los sistemas de archivo de registros, donde los sustitutos acceden a los archivos y no hay claves relacionales, allí son una y la misma cosa).
- Utilice siempre el mismo nombre exacto para la columna de clave dondequiera que se transporte (migre) la PK como FK.
- Por lo tanto, la
user_product
tabla tendrá user_id
un componente de su PK (user_id, product_no)
.
- La relevancia de esto quedará clara cuando comience a codificar. Primero, con
id
muchas tablas, es fácil confundirse en la codificación SQL. En segundo lugar, cualquier otra persona que el codificador inicial no tiene idea de lo que estaba tratando de hacer. Ambos son fáciles de evitar, si las columnas clave se tratan como anteriormente.
La segunda excepción es cuando hay más de un FK que hace referencia a la misma tabla de la tabla principal, que se lleva en el elemento secundario. Según el modelo relacional , use nombres de roles para diferenciar el significado o uso, por ejemplo. AssemblyCode
y ComponentCode
para dos PartCodes
. Y en ese caso, no use el indiferenciado PartCode
para uno de ellos. Se preciso.
Diagrama_E
Prefijo
Cuando tenga más de 100 tablas, prefije los nombres de las tablas con un Área temática:
REF_
para tablas de referencia
OE_
para el clúster de entrada de pedidos, etc.
Solo a nivel físico, no lógico (desordena el modelo).
Sufijo
Nunca use sufijos en las tablas, y siempre use sufijos en todo lo demás. Eso significa que en el uso lógico y normal de la base de datos, no hay guiones bajos; pero en el aspecto administrativo, los guiones bajos se usan como separador:
_V
Ver (con el principal TableName
al frente, por supuesto)
_fk
Clave externa (el nombre de la restricción, no el nombre de la columna) Transacción de segmento de
_cac
caché (proceso almacenado o función) Función (no transaccional), etc.
_seg
_tr
_fn
El formato es el nombre de la tabla o FK, un guión bajo y el nombre de la acción, un guión bajo y, finalmente, el sufijo.
Esto es realmente importante porque cuando el servidor te da un mensaje de error:
____blah blah blah error on object_name
sabes exactamente qué objeto se violó y qué estaba tratando de hacer:
____blah blah blah error on Customer_Add_tr
Claves foráneas (la restricción, no la columna). El mejor nombre para un FK es usar la frase verbal (menos el "cada" y la cardinalidad).
Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk
Use la Parent_Child_fk
secuencia, no Child_Parent_fk
es porque (a) se muestra en el orden correcto cuando los está buscando y (b) siempre conocemos al niño involucrado, lo que estamos adivinando es qué padre. El mensaje de error es entonces encantador:
____ Foreign key violation on Vendor_Offers_PartVendor_fk
.
Eso funciona bien para las personas que se molestan en modelar sus datos, donde se han identificado las frases verbales. Por lo demás, los sistemas de archivo de registro, etc, el uso Parent_Child_fk
.
Los índices son especiales, por lo que tienen una convención de nomenclatura propia, compuesta, en orden , por cada posición de personaje del 1 al 3:
U
Único, o _
para no único
C
en clúster, o _
para no agrupado
_
separador
Para el resto:
Tenga en cuenta que el nombre de la tabla no es obligatorio en el nombre del índice, ya que siempre aparece comotable_name.index_name.
Entonces, cuando Customer.UC_CustomerId
o Product.U__AK
aparece en un mensaje de error, le dice algo significativo. Cuando observa los índices en una tabla, puede diferenciarlos fácilmente.
Encuentre a alguien calificado y profesional y sígalos. Mire sus diseños y estudie cuidadosamente las convenciones de nombres que usan. Hágales preguntas específicas sobre cualquier cosa que no entienda. Por el contrario, huye de cualquiera que demuestre poco respeto por las convenciones o estándares de nombres. Aquí hay algunos para comenzar:
- Contienen ejemplos reales de todo lo anterior. Haga preguntas para cambiar el nombre de las preguntas en este hilo.
- Por supuesto, los modelos implementan varios otros estándares, más allá de las convenciones de nombres; puede ignorarlos por ahora o no dude en hacer nuevas preguntas específicas .
- Son varias páginas cada una, el soporte de imágenes en línea en Stack Overflow es para las aves, y no se cargan constantemente en diferentes navegadores; así que tendrás que hacer clic en los enlaces.
- Tenga en cuenta que los archivos PDF tienen navegación completa, así que haga clic en los botones de cristal azul o en los objetos donde se identifica la expansión:
- Los lectores que no estén familiarizados con el Estándar de modelado relacional pueden encontrar útil la notación IDEF1X .
Ingreso de pedidos e inventario con direcciones que cumplen con los estándares
Sistema simple de boletines entre oficinas para PHP / MyNonSQL
Monitoreo de sensores con capacidad temporal completa
Respuestas a preguntas
Eso no se puede responder razonablemente en el espacio de comentarios.
Larry Lustig:
... incluso el ejemplo más trivial muestra ...
Si un Cliente tiene Productos de cero a muchos y un Producto tiene Componentes de uno a muchos y un Componente tiene Proveedores de uno a muchos y un Proveedor vende cero Componentes para muchos y un SalesRep tiene Clientes uno a muchos ¿Cuáles son los nombres "naturales" de las tablas que contienen Clientes, Productos, Componentes y Proveedores?
Hay dos problemas principales en su comentario:
Declaras que tu ejemplo es "el más trivial", sin embargo, es todo lo contrario. Con ese tipo de contradicción, no estoy seguro de si usted es serio, si técnicamente capaz.
Esa especulación "trivial" tiene varios errores graves de normalización (diseño de base de datos).
Hasta que los corrija, no son naturales ni anormales, y no tienen ningún sentido. También podría nombrarlos anormal_1, anormal_2, etc.
Tienes "proveedores" que no suministran nada; referencias circulares (ilegales e innecesarias); clientes que compran productos sin ningún instrumento comercial (como Factura o Pedido de ventas) como base para la compra (¿o los clientes "poseen" productos?); relaciones de muchos a muchos sin resolver; etc.
Una vez que se normalice, y se identifiquen las tablas requeridas, sus nombres serán obvios. Naturalmente.
En cualquier caso, intentaré atender su consulta. Lo que significa que tendré que darle un poco de sentido, sin saber lo que querías decir, así que ten paciencia conmigo. Los errores graves son demasiados para enumerarlos, y dada la especificación adicional, no estoy seguro de haberlos corregido todos.
Asumiré que si el producto está compuesto de componentes, entonces el producto es un ensamblaje y los componentes se usan en más de un ensamblaje.
Además, dado que el "Proveedor vende componentes de cero a muchos", que no venden productos o ensamblajes, solo venden componentes.
Especulación vs modelo normalizado
En caso de que no lo sepa, la diferencia entre las esquinas cuadradas (Independiente) y las esquinas redondeadas (Dependiente) es significativa, consulte el enlace de notación IDEF1X. Del mismo modo, las líneas continuas (de identificación) frente a las líneas discontinuas (no identificables).
... ¿cuáles son los nombres "naturales" de las tablas que contienen clientes, productos, componentes y proveedores?
- Cliente
- Producto
- Componente (o Componente de ensamblaje, para aquellos que se dan cuenta de que un hecho identifica al otro)
- Proveedor
Ahora que he resuelto las tablas, no entiendo tu problema. Quizás puedas publicar una pregunta específica .
VoteCoffee:
¿Cómo maneja el escenario que Ronnis publicó en su ejemplo donde existen múltiples relaciones entre 2 tablas (user_likes_product, user_bought_product)? Puedo entender mal, pero esto parece dar como resultado nombres de tablas duplicados utilizando la convención que detalló.
Asumiendo que no hay errores de Normalización, User likes Product
es un predicado, no una tabla. No los confundas. Consulte mi Respuesta, donde se relaciona con Sujetos, Verbos y Predicados, y mi respuesta a Larry inmediatamente arriba.
Cada tabla contiene un conjunto de hechos (cada fila es un hecho). Los predicados (o proposiciones) no son hechos, pueden o no ser ciertos.
El modelo relacional se basa en el cálculo de predicados de primer orden (más comúnmente conocido como lógica de primer orden). Un predicado es una oración de una sola cláusula en inglés simple y preciso, que se evalúa como verdadero o falso.
Además, cada tabla representa, o es la implementación de, muchos predicados, no uno.
Una consulta es una prueba de un predicado (o varios predicados, encadenados) que da como resultado verdadero (el hecho existe) o falso (el hecho no existe).
Por lo tanto, las tablas deben nombrarse, como se detalla en mi Respuesta (convenciones de nomenclatura), para la fila, el Hecho y los Predicados deben documentarse (por supuesto, es parte de la documentación de la base de datos), pero como una lista separada de Predicados .
Esto no es una sugerencia de que no son importantes. Son muy importantes, pero no escribiré eso aquí.
Rápidamente, entonces. Dado que el Modelo Relacional se basa en FOPC, se puede decir que toda la base de datos es un conjunto de declaraciones de FOPC, un conjunto de Predicados. Pero (a) hay muchos tipos de Predicados, y (b) una tabla no representa un Predicado (es la implementación física de muchos Predicados y de diferentes tipos de Predicados).
Por lo tanto, nombrar la tabla para "el" Predicar que "representa" es un concepto absurdo.
Los "teóricos" conocen solo unos pocos predicados, no entienden que desde que el RM se fundó en el FOL, toda la base de datos es un conjunto de predicados y de diferentes tipos.
Y, por supuesto, que elijan los absurdos de los pocos que sí saben: EXISTING_PERSON
; PERSON_IS_CALLED
. Si no fuera tan triste, sería muy gracioso.
Tenga en cuenta también que el nombre de la tabla estándar o atómica (nombrando la fila) funciona de manera brillante para todo el verborrea (incluidos todos los predicados adjuntos a la tabla). Por el contrario, el nombre idiota de "tabla representa predicado" no puede. Lo cual está bien para los "teóricos", que entienden muy poco acerca de los predicados, pero retrasados de lo contrario.
Los predicados que son relevantes para el modelo de datos, se expresan en el modelo, son de dos órdenes.
Predicado unario
El primer conjunto es esquemático , no texto: la notación en sí . Estos incluyen varios existenciales; Orientado a la restricción; y predicadores descriptores (atributos).
- Por supuesto, eso significa que solo aquellos que pueden 'leer' un modelo de datos estándar pueden leer esos predicados. Es por eso que los "teóricos", que están severamente paralizados por su mentalidad de solo texto, no pueden leer modelos de datos, por qué se apegan a su mentalidad de solo texto anterior a 1984.
Predicado binario
El segundo conjunto son aquellos que forman relaciones entre hechos. Esta es la línea de relación. La frase verbal (detallada anteriormente) identifica el predicado, la proposición , que se ha implementado (que se puede probar mediante una consulta). Uno no puede ser más explícito que eso.
- Por lo tanto, para quien domina los modelos de datos estándar, todos los predicados relevantes son documentados en el modelo. No necesitan una lista separada de Predicados (¡pero los usuarios, que no pueden 'leer' todo del modelo de datos, lo hacen!).
Aquí hay un modelo de datos , donde he enumerado los predicados. He elegido ese ejemplo porque muestra los predicados existenciales, etc., así como los de relación, los únicos predicados no enumerados son los descriptores. Aquí, debido al nivel de aprendizaje del buscador, lo estoy tratando como un usuario.
Por lo tanto, el evento de más de una tabla secundaria entre dos tablas primarias no es un problema, solo nómbrelas como el hecho existencial en relación con su contenido y normalice los nombres.
Aquí entran en juego las reglas que di para las frases verbales para nombres de relaciones para tablas asociativas. Aquí hay una discusión de Predicate vs Table , que cubre todos los puntos mencionados, en resumen.
Para una buena descripción breve sobre el uso adecuado de los predicados y cómo usarlos (que es un contexto bastante diferente al de responder a los comentarios aquí), visite esta respuesta y desplácese hacia abajo a la sección de predicados .
Charles Burns:
Por secuencia, me refería al objeto de estilo Oracle utilizado exclusivamente para almacenar un número y su siguiente según alguna regla (por ejemplo, "agregar 1"). Como Oracle carece de tablas de identificación automática, mi uso típico es generar identificaciones únicas para las PK de tabla. INSERTAR EN LOS VALORES foo (id, somedata) (foo_s.nextval, "data" ...)
Ok, eso es lo que llamamos una tabla Key o NextKey. Nómbralo como tal. Si tiene SubjectAreas, use COM_NextKey para indicar que es común en la base de datos.
Por cierto, ese es un método muy pobre para generar claves. No es escalable en absoluto, pero luego, con el rendimiento de Oracle, probablemente esté "bien". Además, indica que su base de datos está llena de sustitutos, no relacionales en esas áreas. Lo que significa un rendimiento extremadamente pobre y falta de integridad.
primarily opinion-based
es evidentemente falso.