una - modificar columna auto_increment sql server

Nombrar columnas de ID en tablas de base de datos (24)

Me preguntaba las opiniones de las personas 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, llamaría a esa columna InvoiceID para no entrar en conflicto con otras tablas y es obvio de lo que se trata.

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

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. Debería alias las columnas en la selección
2. ID = InvoiceID no cabe en mi cerebro
3. Si no aliaste las tablas y se refirió a InvoiceID ¿es obvio en qué tabla está?

¿Cuáles son los pensamientos de otras personas sobre el tema?

Últimamente ha habido una pelea de nerds sobre esto en mi compañía. El advenimiento de LINQ ha hecho que el patrón redundante tablename + ID sea aún más obviamente tonto a mis ojos. Creo que la mayoría de las personas razonables dirán que si escribe manualmente su SQL de modo que tenga que especificar los nombres de las tablas para diferenciar los FK, entonces no solo se ahorrará al escribir, sino que también le dará claridad a su SQL para usar solo la ID en la que se puede ver claramente cuál es el PK y cuál es el FK .

P.ej

DESDE Empleados e LEFT JOIN 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 viejo estilo te ves forzado a mirar o esperar que tengan un buen nombre.

Acabo de empezar a trabajar en un lugar que utiliza solo "ID" (en las tablas centrales, a las que hace referencia TableNameID en claves externas), y ya he encontrado DOS problemas de producción causados directamente por él.

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

¿Alguien puede decir honestamente que no habría sido mucho más fácil detectar si se usaran nombres completos y consistentes donde la declaración incorrecta habría sido "... donde está TransID in (SELECCIONAR OtherTableID from OtherTable ..."? No creo asi que.

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

Si la meta es generar errores innecesarios (¿quizás algunas personas no tienen suficiente trabajo?), Entonces este tipo de convención de nombres es genial. De lo contrario, dar un nombre consistente es el camino a seguir.

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

Van un paso más allá para ayudar a entender las claves foráneas: la clave foránea en la tabla de productos que hace referencia a la tabla de categorías sería idctg_prd para que sea obvio a qué tabla pertenece (sufijo _prd ) ya qué tabla se refiere ( categoría).

Las ventajas son que no hay ambigüedad con las columnas de identidad en tablas diferentes, y que puede decir de un vistazo a qué columnas hace referencia una consulta por los nombres de columna.

Creo que puedes usar cualquier cosa para la "ID" mientras seas consecuente. Incluir el nombre de la tabla es importante para. Sugeriría usar una herramienta de modelado como Erwin para hacer cumplir las convenciones y estándares de nomenclatura, de modo que al escribir las consultas es fácil entender las relaciones que pueden existir entre las tablas.

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

Saludos, Ben

Definitivamente estoy de acuerdo con incluir el nombre de la tabla en el nombre del campo de ID, exactamente por los motivos que das. En general, este es el único campo donde incluiría el nombre de la tabla.

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

En vista de 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, aunque a veces se requieren términos calificativos adicionales basados en el contexto, por ejemplo, el elemento de datos llamado employee_ID podría usarse dos veces en el organigrama y, por lo tanto, calificado como supervisor_employee_ID y subordinate_employee_ID respectivamente.

Obviamente, las convenciones de nombres son subjetivas y una cuestión de estilo. He encontrado que las pautas ISO / IEC 11179 son un punto de partida útil.

Para el DBMS, veo las tablas como colecciones de entidades (excepto aquellas que solo contienen una fila, por ejemplo, una tabla de cofres, una tabla de constantes, etc.), por ejemplo, la tabla donde mi ID_de_empleado se llamará Personnel . Así que de inmediato la convención TableNameID no funciona para mí.

He visto el TableName.ID=PK TableNameID=FK estilo TableName.ID=PK TableNameID=FK utilizado en modelos de datos grandes y tengo que decir que me resulta un poco confuso: prefiero que el nombre de un identificador sea el mismo en todas partes, es decir, no cambia el nombre según la tabla en la que suceda para aparecer. Algo para notar es que el estilo mencionado anteriormente se usa en las tiendas que agregan una columna de IDENTITY (autoincremento) a cada tabla mientras se evitan las claves naturales y compuestas en las claves foráneas. Esas tiendas tienden a no tener diccionarios de datos formales ni compilar a partir de modelos de datos. Una vez más, esto es simplemente una cuestión de estilo y no me suscribo personalmente. Entonces, en definitiva, no es para mí.

Dicho todo esto, puedo ver un caso en el que a veces se descarta el calificador del nombre de la columna cuando el nombre de la tabla proporciona un contexto para hacerlo, por ejemplo, el elemento llamado employee_last_name puede convertirse simplemente en last_name en la tabla de Personnel . El razonamiento aquí es que el dominio es ''apellidos de las personas'' y es más probable que esté UNION ed con columnas last_name de otras tablas en lugar de ser usado como una clave externa en otra tabla, pero luego otra vez ... Podría cambiar mi nombre mente, a veces nunca puedes decir. Esa es la cuestión: el modelado de datos es parte arte, parte ciencia.

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 listaban el OtherTable + Id.

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

En mi posición actual, estamos empleando el marco de la entidad utilizando la generación de POCO. Utilizando la convención de nomenclatura estándar de Id, la PK permite la herencia de una clase base baja con validación y tal para las 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 utilizar una clase base para estos.

Solo algo de reflexión.

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

Nombres de campo de base de datos en minús
Nombres de tablas en mayúsculas
Use guiones bajos para separar palabras en el nombre del campo: conviértalas al caso de Pascal en el código.
pk_ prefix significa clave principal
_id sufijo significa un entero, identificación de auto incremento
fk_ prefix significa clave foránea (no es necesario el sufijo)
_VW sufijo para vistas
is_ prefix para booleanos

Entonces, una tabla llamada NAMES podría tener los campos pk_name_id, first_name, last_name, is_alive, y fk_company y una vista llamada LIVING_CUSTOMERS_VW , definida como:

SELECT first_name, last_name FROM CONTACT.NAMES WHERE (is_alive = ''True'')

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

ID es un SQL Antipattern. 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 identificación que está haciendo, informar es mucho más difícil. Oculta el significado y hace que las consultas complejas sean más difíciles de leer y requiere que use alias para diferenciarse en el informe.

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

Si desea utilizar la sintaxis de USING que algunos dbs permiten, no puede usar ID.

Si usa ID, puede terminar fácilmente con una combinación errónea si está copiando la sintaxis de unión (¡no me diga que nadie lo hace!) Y olvide 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 te referías

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 id, este tipo de error accidental es mucho menos probable y mucho más fácil de encontrar.

Lo que hago para mantener las cosas consistentes para mí (donde una tabla tiene una sola clave primaria de columna utilizada como ID) es nombrar la clave principal de la tabla Table_pk . Dondequiera que tenga una clave externa que apunte a esa clave primaria de tablas, llamo a la columna PrimaryKeyTable_fk . De esa manera sé que si tengo un Customer_pk en mi tabla de clientes y un Customer_fk en 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

Mi preferencia también es ID para clave primaria 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 aplicación en sí, puedo manejar tablas en masa, de la misma manera. Esto es algo muy poderoso. Por lo general, se crea un software OO en la parte superior de la base de datos, pero el conjunto de herramientas OO no se puede aplicar porque el propio db no lo permite. Tener las columnas ID y nombre todavía no es muy bueno, pero es un paso.

Seleccionar
i.ID, il.ID de Facturas i Left Únase a 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 legible y simple. Nombrar variables como i y il es una opción pobre en general.

Mi voto es para InvoiceID para la ID de la tabla. También uso 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

Claro, es más largo que algunos otros ejemplos. Pero sonríe. Esto es para la posteridad y algún día, algún pobre codificador junior va a tener que alterar su obra maestra. En este ejemplo, no hay ambigüedad y, a medida que se agregan tablas adicionales a la consulta, estará agradecido por la verbosidad.

No es realmente importante, es probable que se encuentre con problemas simalares en todas las convenciones de nombres.

Pero es importante ser constante para que no tenga que mirar las definiciones de la tabla cada vez que escriba una consulta.

Odio el nombre de identificación simple. 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 ID más utilizados. Eso fue un infierno total.

Para cada tabla elijo una taquigrafía de letra de árbol (p. Ej. Empleados => Emp)

De esta forma, una clave primaria de autonumeración numérica se convierte en nkEmp .

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

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

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 llamarlo "ID" allí, si es la única identificación en la estructura.

Si la columna NO se va a utilizar en una clave externa, de modo que solo se use para identificar de manera única una fila para edición o eliminación, la denominaré "PK".

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

DomainName suele ser, pero no siempre, lo mismo que TableName.

El problema con la ID por sí solo es que no escala hacia arriba. Una vez que tenga alrededor de 200 tablas, cada una con una primera columna llamada ID, los datos comienzan a parecer todos iguales. Si siempre calificas la identificación con el nombre de la tabla, eso ayuda un poco, pero no tanto.

DomainName & ID se puede usar para nombrar claves externas así como claves principales. Cuando las claves foriegn llevan el nombre de la columna a la que hacen referencia, eso puede ser de ayuda nemoté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 tremendamente útil cuando se trata de leer consultas y actualizaciones.

Ocasionalmente, DomainName || ''ID'' no se puede usar, 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, utilizo teclas naturales en lugar de teclas 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 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'' en él. Ejemplo: OrderNo donde No es la abreviatura de "Number".

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

Use apodos cortos (3-4 caracteres) para los nombres de las tablas, es decir, Factura - inv , Facturas - invl
Nombre las columnas en la tabla usando esos apodos, es decir inv_id , invl_id
Para las columnas de referencia, use invl_inv_id para los nombres.

de esta manera podrías decir

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id

Si le da a cada clave un nombre único, por ejemplo, "facturas.número_de_viaje" en lugar de "facturas.id", entonces puede utilizar los operadores de "unión natural" y "usar" sin preocupaciones. P.ej

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

en lugar de

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

SQL es suficientemente detallado sin hacer que sea más detallado.

Siempre preferí ID a TableName + ID para la columna id y luego TableName + ID para una clave externa. De esta forma, todas las tablas tienen el mismo nombre para el campo de identificación 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 mesas y no saber qué campo Id pertenece a qué tabla, en mi opinión la consulta debe escribirse para manejar esta situación. Donde trabajo, siempre preferimos los campos que usamos en una declaración con el alias tabla / tabla.

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

también vea la convención de nomenclatura de clave primaria / clave externa

Personalmente prefiero (como se ha indicado anteriormente) el Table.ID para el PK y el TableID para el FK . Incluso (no me dispare) Microsoft Access recomienda esto.

SIN EMBARGO, TAMBIÉN sé de hecho 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 para cada consulta que usted crea, termina estafando todas las relaciones innecesarias recién creadas en todas las tablas en la columna ID)

POR LO TANTO como mi TOC interno lo odia, me refiero a la convención TableID . Recordemos que se llama BASE de Datos, ya que será la base para, afortunadamente, muchas y muchas aplicaciones futuras. Y todas las tecnologías deberían beneficiarse de un esquema bien normalizado con una descripción clara.

Ni que decir tiene que ESTOY dibujando mi línea cuando las personas comienzan a usar TableName, TableDescription y tal. 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 que debo hacer sentadillas. Así que a veces hago algo como Store.EmployeeID_Manager . Claro que es un poco más grande pero al menos las personas no se volverán locas tratando de encontrar Table Manager ID , o lo que EmployeeID está haciendo allí. Cuando consultar es DONDE lo simplificaría como: SELECCIONE EmployeeID_Manager como ID de administrador FROM Store