Nombrar las columnas de ID en las tablas de la base de datos

Me preguntaba las opiniones de la gente sobre el nombre de las columnas de ID en las tablas de la base de datos.

Si tengo una tabla llamada Facturas con una clave principal de una columna de identidad, la llamaría InvoiceID para no entrar en conflicto con otras tablas y es obvio cuál es.

Donde estoy trabajando actualmente, han llamado a todas las columnas de ID ID.

Entonces harían lo siguiente:

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

Ahora, veo algunos problemas aquí:
1. Necesitarías poner un alias a las columnas en la selección
2. ID = InvoiceID no cabe en mi cerebro
3. Si no pusiste un alias en las tablas y te refieres a InvoiceID, es obvio qué tabla ¿está en?

¿Qué piensan otras personas sobre el tema?

ID es un antipatrón SQL. Consulte http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a

Si tiene muchas tablas con ID como ID, está haciendo que los informes sean mucho más difíciles. Oculta el significado y hace que las consultas complejas sean más difíciles de leer, además de requerir el uso de alias para diferenciar el informe.

Además, si alguien es lo suficientemente tonto como para usar una combinación natural en una base de datos donde está disponible, se unirá a los registros incorrectos.

Si desea usar la sintaxis USING que permiten algunos dbs, no puede hacerlo si usa ID.

Si usa ID, puede terminar fácilmente con una unión errónea si está copiando la sintaxis de unión (¡no me diga que nadie hace esto!) Y se olvida de cambiar el alias en la condición de unión.

Entonces ahora tienes

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

cuando quisiste decir

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

Si usa tablenameID como el campo de identificación, este tipo de error accidental es mucho menos probable y más fácil de encontrar.

Siempre preferí ID a TableName + ID para la columna de identificación y luego TableName + ID para una clave externa. De esa manera, todas las tablas tienen el mismo nombre para el campo id y no hay una descripción redundante. Esto me parece más simple porque todas las tablas tienen el mismo nombre de campo de clave principal.

En cuanto a unir tablas y no saber qué campo Id pertenece a qué tabla, en mi opinión, la consulta debería escribirse para manejar esta situación. Donde trabajo, siempre damos preferencia a los campos que usamos en una declaración con el alias de tabla / tabla.

Últimamente ha habido una pelea de nerds sobre esto mismo en mi compañía. La llegada de LINQ ha hecho que el patrón redundante de nombre de tabla + ID sea aún más obviamente tonto en mi opinión. Creo que la mayoría de las personas razonables dirán que si está escribiendo a mano su SQL de tal manera que tenga que especificar los nombres de las tablas para diferenciar los FK, entonces no solo es un ahorro al escribir, sino que agrega claridad a su SQL para usar solo el ID en el que puede ver claramente cuál es el PK y cuál es el FK .

P.ej

DE Empleados e IZQUIERDA UNIRSE A Clientes c ON e.ID = c.EmployeeID

Me dice no solo que los dos están vinculados, sino cuál es el PK y cuál es el FK . Mientras que en el estilo antiguo te ves obligado a mirar o esperar que tengan un buen nombre.

Usamos InvoiceID, no ID. Hace que las consultas sean más legibles: cuando ve IDsolo, podría significar cualquier cosa, especialmente cuando se asigna un alias a la tabla i.

Estoy de acuerdo con Keven y algunas otras personas aquí en que el PK para una tabla debería ser simplemente Id y las claves externas enumeran OtherTable + Id.

Sin embargo, deseo agregar una razón que recientemente dio más peso a este argumento.

En mi puesto actual, estamos empleando el marco de la entidad utilizando la generación de POCO. Usando la convención de nomenclatura estándar de Id, la PK permite la herencia de una clase base poco con validación y similares para tablas que comparten un conjunto de nombres de columna comunes. El uso de Tablename + Id como PK para cada una de estas tablas destruye la capacidad de usar una clase base para estas.

Solo algo para pensar.

Mi preferencia también es ID para clave principal y TableNameID para clave externa. También me gusta tener un "nombre" de columna en la mayoría de las tablas donde guardo el identificador legible por el usuario (es decir, el nombre :-)) de la entrada. Esta estructura ofrece una gran flexibilidad en la propia aplicación, puedo manejar mesas en masa, de la misma forma. Esto es un muy poderoso. Por lo general, un software OO se construye sobre la base de datos, pero el conjunto de herramientas OO no se puede aplicar porque la propia base de datos no lo permite. Tener la identificación y el nombre de las columnas todavía no es muy bueno, pero es un paso.

Seleccione
i.ID, il.ID de Invoices i Left Join InvoiceLines il en i.ID = il.InvoiceID

¿Por qué no puedo hacer esto?

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

En mi opinión, esto es muy sencillo y legible. En general, nombrar las variables como i e il es una mala elección.

No es realmente importante, es probable que tenga problemas de simalar en todas las convenciones de nomenclatura.

Pero es importante ser coherente para no tener que mirar las definiciones de la tabla cada vez que escribe una consulta.

Acabo de comenzar a trabajar en un lugar que usa solo "ID" (en las tablas principales, referenciado por TableNameID en claves externas), y ya encontré DOS problemas de producción causados ​​directamente por él.

En un caso, la consulta utilizó "... donde ID en (SELECT ID FROM OtherTable ..." en lugar de "... donde ID en (SELECT TransID FROM OtherTable ...").

¿Alguien puede decir honestamente que no habría sido mucho más fácil de detectar si se usaran nombres completos y consistentes donde la declaración incorrecta hubiera leído "... donde TransID en (SELECT OtherTableID from OtherTable ..."? No creo entonces.

El otro problema ocurre cuando se refactoriza el código. Si usa una tabla temporal mientras que anteriormente la consulta salía de una tabla principal, entonces el código antiguo dice "... dbo.MyFunction (t.ID) ..." y si eso no se cambia pero "t" ahora se refiere a un temp table en lugar de la tabla principal, ni siquiera obtiene un error, solo resultados erróneos.

Si generar errores innecesarios es un objetivo (¿quizás algunas personas no tienen suficiente trabajo?), Entonces este tipo de convención de nomenclatura es excelente. De lo contrario, la denominación coherente es el camino a seguir.

En aras de la simplicidad, la mayoría de las personas nombran la columna en el ID de la tabla. Si tiene una referencia de clave externa en otra tabla, entonces lo llaman explícitamente InvoiceID (para usar su ejemplo) en el caso de uniones, de todos modos está creando un alias en la tabla, por lo que el inv.ID explícito es aún más simple que inv.InvoiceID

Yo personalmente prefiero (como se ha indicado anteriormente) el Table.ID para el PK y TableID para el FK . Incluso (por favor, no me disparen) Microsoft Access recomienda esto.

SIN EMBARGO, TAMBIÉN sé con certeza que algunas herramientas de generación favorecen el TableID para PK porque tienden a vincular todos los nombres de columna que contienen 'ID' en la palabra, INCLUYENDO ID !!!

Incluso el diseñador de consultas hace esto en Microsoft SQL Server (y por cada consulta que crea, termina eliminando todas las relaciones innecesarias recién creadas en todas las tablas en la ID de columna)

ASÍ, por mucho que mi TOC interno lo odie, sigo la convención TableID . Recordemos que se llama BASE de datos , ya que será la base de muchas aplicaciones futuras. Y todas las tecnologías deben beneficiarse de un esquema bien normalizado con una descripción clara.

No hace falta decir que SÍ trazo mi línea cuando la gente comienza a usar TableName, TableDescription y demás. En mi opinión, las convenciones deberían hacer lo siguiente:

• Nombre de la tabla: pluralizado. Ex. Empleados

• Alias ​​de la tabla: Nombre completo de la tabla, singularizado. Ex.

  SELECT Employee.*, eMail.Address
  FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well

[Actualizar]

Además, hay algunas publicaciones válidas en este hilo sobre columnas duplicadas debido al "tipo de relación" o rol. Por ejemplo, si una tienda tiene un EmployeeID , eso me dice en cuclillas. Entonces, a veces hago algo como Store.EmployeeID_Manager . Seguro que es un poco más grande, pero al menos la gente no se volverá loca tratando de encontrar la tabla ManagerID , o lo que EmployeeID está haciendo allí. Cuando la consulta es DONDE lo simplificaría como: SELECT EmployeeID_Manager como ManagerID FROM Store

Llegando a esto desde la perspectiva de un diccionario de datos formal, nombraría el elemento de datos invoice_ID. Generalmente, el nombre de un elemento de datos será único en el diccionario de datos e idealmente tendrá el mismo nombre en todas partes, aunque a veces se pueden requerir términos de calificación adicionales según el contexto, por ejemplo, el elemento de datos nombrado employee_IDpodría usarse dos veces en el organigrama y, por lo tanto, calificarse como supervisor_employee_IDy subordinate_employee_IDrespectivamente.

Obviamente, las convenciones de nomenclatura son subjetivas y una cuestión de estilo. Creo que las directrices ISO / IEC 11179 son un punto de partida útil.

Para el DBMS, veo tablas como colecciones de entidades (excepto aquellas que solo contienen una fila, por ejemplo, tabla de cofig, tabla de constantes, etc.), por ejemplo, la tabla donde my employee_IDes la clave se nombraría Personnel. Así que de inmediato la TableNameIDconvención no me funciona.

He visto el TableName.ID=PK TableNameID=FKestilo utilizado en modelos de datos grandes y debo decir que lo encuentro un poco confuso: prefiero que el nombre de un identificador sea el mismo en todas partes, es decir, que no cambie el nombre en función de la tabla en la que aparece. Algo a tener en cuenta es el estilo mencionado anteriormente parece usarse en las tiendas que agregan una IDENTITYcolumna (de incremento automático) a cada tabla mientras rechazan las claves naturales y compuestas en las claves externas. Esas tiendas tienden a no tener diccionarios de datos formales ni a construir a partir de modelos de datos. Una vez más, esto es simplemente una cuestión de estilo y una a la que no me suscribo personalmente. Entonces, en última instancia, no es para mí.

Dicho todo esto, puedo ver un caso para eliminar a veces el calificador del nombre de la columna cuando el nombre de la tabla proporciona un contexto para hacerlo, por ejemplo, el elemento nombrado employee_last_namepuede convertirse simplemente last_nameen la Personneltabla. El razonamiento aquí es que el dominio son los 'apellidos de las personas' y es más probable que se UNIONedite con last_namecolumnas de otras tablas en lugar de usarse como una clave externa en otra tabla, pero, de nuevo ... podría cambiar de opinión, a veces nunca se sabe. Esa es la cuestión: el modelado de datos es en parte arte, en parte ciencia.

Creo que puedes usar cualquier cosa para el "ID" siempre que seas consistente. Es importante incluir el nombre de la tabla. Sugeriría usar una herramienta de modelado como Erwin para hacer cumplir las convenciones y estándares de nomenclatura para que al escribir consultas sea fácil comprender las relaciones que pueden existir entre las tablas.

Lo que quiero decir con la primera declaración es que, en lugar de ID, puede usar algo más como 'recno'. Entonces esta tabla tendría un PK de invoice_recno y así sucesivamente.

Saludos, Ben

Mi voto es por InvoiceID para el ID de la mesa. También utilizo la misma convención de nomenclatura cuando se usa como clave externa y uso nombres de alias inteligentes en las consultas.

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

Seguro, es más largo que otros ejemplos. Pero sonríe. Esto es para la posteridad y algún día, algún pobre programador junior tendrá que alterar tu obra maestra. En este ejemplo no hay ambigüedad y, a medida que se agregan tablas adicionales a la consulta, agradecerá la verbosidad.

Para el nombre de la columna en la base de datos, usaría "InvoiceID".

Si copio los campos en una estructura sin nombre a través de LINQ, puedo nombrarla "ID" allí, si es la única ID en la estructura.

Si la columna NO se usará en una clave externa, de modo que solo se use para identificar de manera única una fila para editar, editar o eliminar, la llamaré "PK".

Si le da a cada clave un nombre único, por ejemplo, "invoices.invoice_id" en lugar de "invoices.id", entonces puede usar los operadores "natural join" y "using" sin preocupaciones. P.ej

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

en vez de

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

SQL es lo suficientemente detallado sin hacerlo más detallado.

Lo que hago para mantener las cosas consistentes para mí (donde una tabla tiene una clave principal de una sola columna utilizada como ID) es nombrar la clave principal de la tabla Table_pk. En cualquier lugar donde tenga una clave externa que apunta a la clave principal de la tabla, llamo a la columna PrimaryKeyTable_fk. De esa manera, sé que si tengo un Customer_pken mi tabla de Clientes y un Customer_fken mi tabla de Pedidos, sé que la tabla de Pedidos se refiere a una entrada en la tabla de Clientes.

Para mí, esto tiene sentido especialmente para las uniones donde creo que se lee más fácil.

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk

FWIW, nuestro nuevo estándar (que cambia, eh, quiero decir "evoluciona", con cada nuevo proyecto) es:

• Nombres de campo de base de datos en minúsculas
• Nombres de tablas en mayúsculas
• Utilice guiones bajos para separar palabras en el nombre del campo; conviértalas a mayúsculas y minúsculas en el código.
• pk_ prefijo significa clave primaria
• _id sufijo significa un número entero, ID de incremento automático
• fk_ prefijo significa clave externa (no se necesita sufijo)
• _VW sufijo para vistas
• is_ prefijo para booleanos

Por lo tanto, una tabla llamada NOMBRES podrían tener los campos pk_name_id, first_name, last_name, is_alive,y fk_companyy una vista llamada LIVING_CUSTOMERS_VW, que se define como:

SELECCIONAR nombre, apellido
DE NOMBRES DE CONTACTO
DONDE (is_alive = 'True')

Sin embargo, como han dicho otros, casi cualquier esquema funcionará siempre que sea consistente y no ofusque innecesariamente sus significados.

Definitivamente estoy de acuerdo con incluir el nombre de la tabla en el nombre del campo ID, exactamente por las razones que usted da. Generalmente, este es el único campo en el que incluiría el nombre de la tabla.

Odio el nombre simple de identificación. Prefiero usar siempre el invoice_id o una variante del mismo. Siempre sé qué tabla es la tabla autorizada para la identificación cuando lo necesito, pero esto me confunde

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID 

Lo peor de todo es la mezcla que mencionas, totalmente confusa. Tuve que trabajar con una base de datos donde casi siempre era foo_id, excepto en uno de los identificadores más usados. Eso fue un infierno total.

Prefiero DomainName || 'CARNÉ DE IDENTIDAD'. (es decir, nombre de dominio + ID)

DomainName es a menudo, pero no siempre, el mismo que TableName.

El problema con el ID en sí mismo es que no se escala hacia arriba. Una vez que tenga alrededor de 200 tablas, cada una con una primera columna llamada ID, los datos comienzan a verse todos iguales. Si siempre califica ID con el nombre de la tabla, eso ayuda un poco, pero no tanto.

DomainName & ID se pueden usar para nombrar claves externas así como claves primarias. Cuando las claves foriegn reciben el nombre de la columna a la que hacen referencia, eso puede ser de ayuda mnemotécnica. Formalmente, no es necesario vincular el nombre de una clave externa a la clave a la que hace referencia, ya que la restricción de integridad referencial establecerá la referencia. Pero es muy útil cuando se trata de leer consultas y actualizaciones.

Ocasionalmente, DomainName || No se puede usar 'ID' porque habría dos columnas en la misma tabla con el mismo nombre. Ejemplo: Employees.EmployeeID y Employees.SupervisorID. En esos casos, uso RoleName || 'ID', como en el ejemplo.

Por último, pero no menos importante, uso claves naturales en lugar de claves sintéticas cuando es posible. Hay situaciones en las que las claves naturales no están disponibles o no son confiables, pero hay muchas situaciones en las que la clave natural es la elección correcta. En esos casos, dejo que la clave natural tome el nombre que naturalmente tendría. Este nombre a menudo ni siquiera tiene las letras "ID". Ejemplo: OrderNo donde No es una abreviatura de "Número".

Para cada tabla, elijo una abreviatura de letras de árbol (por ejemplo, Empleados => Emp)

De esa forma, una clave primaria numérica autonumérica se convierte en nkEmp .

Es breve, único en toda la base de datos y conozco exactamente sus propiedades de un vistazo.

Mantengo los mismos nombres en SQL y en todos los lenguajes que uso (principalmente C #, Javascript, VB6).

Consulte las convenciones de nomenclatura del sitio de Interakt para obtener un sistema bien pensado de tablas de nomenclatura y columnas. El método utiliza un sufijo para cada tabla ( _prdpara una tabla de productos o _ctgpara una tabla de categorías) y lo agrega a cada columna de una tabla determinada. Entonces, la columna de identidad para la tabla de productos sería id_prdy, por lo tanto, es única en la base de datos.

Van un paso más allá para ayudar a comprender las claves externas: la clave externa en la tabla de productos que se refiere a la tabla de categorías sería idctg_prdpara que sea obvio a qué tabla pertenece ( _prdsufijo) y a qué tabla se refiere (categoría) .

Las ventajas son que no hay ambigüedad con las columnas de identidad en diferentes tablas y que puede saber de un vistazo a qué columnas se refiere una consulta por los nombres de las columnas.

ver también Convención de nomenclatura de clave primaria / clave externa

Puede utilizar la siguiente convención de nomenclatura. Tiene sus defectos pero resuelve tus problemas particulares.

1. Utilice apodos cortos (3-4 caracteres) para los nombres de las tablas, es decir, Factura - inv, Líneas de factura -invl
2. Nombra las columnas de la tabla usando esos apodos, es decir inv_id,invl_id
3. Para las columnas de referencia, utilice invl_inv_idpara los nombres.

de esta manera podrías decir

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id