Me pregunto cuál es la mejor práctica para nombrar claves principales/únicas en una base de datos con muchas tablas. ¿Debería siempre llamar a la clave principal de cada tabla id o está bien para no tener un campo id en cada tabla y simplemente nombrar cada uno de ellos something1_id, something2_id, etc.?Dar nombre a las claves principales "id" frente a "something_id" en SQL
Hagas lo que hagas, elige una u otra y sigue ese estándar. Existen ventajas y desventajas para cada uno.
Prefiero SomethingID pero otras personas prefieren solo ID. En el sistema con el que trabajo hay más de mil tablas y tener el PK y el FK con los mismos nombres hace las cosas más fáciles.
hola KM, gracias. Así que mientras no haya una manera claramente superior, creo que me quedaré con 'somethingID'. –
@tim peterson, todo depende de cómo uses SQL y lo que funcione para ti. El punto clave de la consulta es recuperar la información rápidamente, y el nombre de la columna no afectará eso, el uso del índice sí lo hará. –
Lo peor es que los DB utilizan más de una convención de nomenclatura. Trabajé en un sistema que usaba 4 convenciones de nombres diferentes para PKs sustitutos. –
Es una preferencia personal. Al final del día no hace absolutamente ninguna diferencia. Personalmente prefiero usar solo Id ya que me parece que consultar el campo (digamos Customer tabla y Id campo) Customer.CustomerId es incómodo, donde Customer.Id parece tener más sentido.
Sugiero que use una abreviatura para nombres largos y use (algo) Id (como user_id) para las tablas normales. Por lo tanto, para la tabla customer_company_relation_metadata, use ccm_id. Pero está bien usar id así como
No use abreviaturas en este contexto, solo ofusca su código y es menos legible para los nuevos (más) miembros de su equipo/código (e incluso usted mismo después de un descanso). Buen material de lectura: http://programmers.stackexchange.com/a/24083 – Styxxy
@Styxxy He encontrado que es la forma más útil entre tener nombres de columna largos (que son molestos en consultas más largas) y tener que usar 'usuario. id' todo el tiempo. Pero es, por supuesto, una cuestión de gusto. –
Los nombres muy largos se pueden abreviar, tal vez.Sin embargo, no lo usaría para el usuario (¿cuáles son esas 2 letras si paga mucho en legibilidad?). De hecho, es en parte su preferencia, pero la abreviatura abreviar es simplemente incorrecta (no me gustaría mantener el código así). PD: si tienes un editor decente, incluso los nombres largos no deberían importar. – Styxxy
id es solo una convención conveniente: puede llamar al campo cualquier cosa siempre que lo declare como un campo clave.
La prefijación de la identificación con un contexto relevante puede ser útil cuando se trata de leer y escribir su código, y mejora especialmente la legibilidad cuando se unen datos de varias tablas y claves externas.
(* Solo un pensamiento porque su respuesta me llamó la atención y estaba pensando en programar en una interfaz. *) Es cierto, y estoy de acuerdo, pero el enfoque 'id' traduce mejor los registros de las tablas a los objetos, especialmente si tiene un super abstracto -clase con una propiedad 'id'. Si haces lo que sugieres (lo cual sucede que hago también), también debes administrar los diversos campos y propiedades de 'blahId' al mapear registros de tabla a objetos. Eso sería cierto para las claves externas que se traducen a propiedades de objeto de todos modos, pero al menos la superclase abstracta podría tener una propiedad simple llamada 'id'. –
Puede tener una propiedad 'id' de todos modos, pero su código sería más consistente horizontalmente en superclases abstractas si usamos el' id', especialmente cuando asignamos el valor del campo 'id' a la propiedad' id'. La claridad de la base de datos puede sufrir un poco, pero eso se puede mitigar dando nombres de claves externas 'blahId'. Esos nombres se filtrarán en los objetos, pero podrás saber qué es qué. –
Es es una cuestión de preferencia; sin embargo, existe la ventaja de usar ID (algo) en los nombres de las columnas que se vuelven menos ambiguos cuando se realizan uniones entre tablas.
sí, gracias, estoy de acuerdo, esta pregunta surgió cuando escribí más y más UNIONES ... –
Hay una ventaja para ambos al hacer uniones. Prefiero 'id' para el nombre de la columna, ya que voy a enumerar los nombres de las tablas antes de las columnas en * all * joins de todos modos, por lo que' tablename_id' o algo similar es solo una especificidad extra, innecesaria. – 0b10011
@bfrohs: Sí, estoy de acuerdo en incluir el nombre de la tabla en el nombre de la columna de ID implica un poco más de mecanografía. –
Hay racimos de artículos hacia fuera allí, ir a comprobar éste hacia fuera ...
¡Y lo más importante, como dijo KM anteriormente, elija uno y cúmplalo! – larryr
'something_id' es redundante cuando se puede usar' table.id' todas partes ... a menos que seas poniendo una clave foránea –
Siempre me he preguntado qué opinan las personas sobre los pros y contras de los enfoques – erikkallen
el problema de la clave foránea es la razón por la cual "ID" puede ser confuso, porque luego tiene que crear una relación con "somethingID" en una tabla diferente; estás creando relaciones en campos con diferentes nombres. – niico