Diseño de base de datos: convenciones de nomenclatura de teclas principales

Question

Estoy interesado en saber qué piensa la gente acerca de (Y POR QUÉ) las siguientes 3 convenciones diferentes para nombrar claves primarias de tabla de base de datos en MySQL?

-Ejemplo 1-

Tabla nombre: Usuario,
Primaria nombre de la clave de la columna: user_id

-Ejemplo 2-

Tabla nombre: Usuario,
Primaria nombre de clave columna: id

-Ejemplo 3-

nombre de tabla: U Ser,
Primaria nombre de la columna clave: pk_user_id

Sólo quiero escuchar las ideas y tal vez aprender algo en el proceso :)

Gracias.

Answer 1

Siempre he apreciado la toma de Justinsomnia en las convenciones de nombres de bases de datos. Darle una lectura: http://justinsomnia.org/2003/04/essential-database-naming-conventions-and-style/

Answer 2

que sugeriría el ejemplo 2. De esta manera no hay ninguna ambigüedad entre claves ajenas y claves primarias, ya que es en el ejemplo 1. Se puede hacer, por ejemplo,

SELECT * FROM user, comment WHERE user.id = comment.user_id 

que es claro y conciso.

El tercer ejemplo es redundante en un diseño donde todos los identificadores se utilizan como claves principales.

Answer 3

Me gustaría ir con la opción 2. Para mí, "id" en sí parece suficiente. Dado que la tabla es Usuario, la columna "id" dentro de "usuario" indica que es el criterio de identificación para el usuario.

Sin embargo, debo agregar que las convenciones de nomenclatura tienen que ver con la coherencia. Normalmente no hay correcto/incorrecto siempre y cuando haya un patrón consistente y se aplique en toda la aplicación, ese es probablemente el factor más importante en cuán efectivas serán las convenciones de nomenclatura y cuán lejos van a hacer que la aplicación sea más fácil de entender y por lo tanto mantener.

Answer 4

Siempre prefiero la opción en el ejemplo 1, en el que el nombre de la tabla se utiliza (redundantemente) en el nombre de la columna. Esto se debe a que prefiero ver ON user.user_id = history.user_id que ON user.id = history.user_id en JOINs.

Sin embargo, el peso de la opinión general sobre este tema parece correr contra mí aquí en Stackoverflow, donde la mayoría de la gente prefiere el ejemplo 2.

Por cierto, prefiero ID de usuario a USER_ID como una convención de nombres de columna. No me gusta escribir guiones bajos, y el uso del guión bajo como el carácter común de un solo carácter de SQL a veces puede ser un poco confuso.

Answer 5

Tiendo a ir con la primera opción, user_id.

Si va con id, generalmente necesita alias excesivamente en sus consultas. Si va con more_complicated_id, entonces debe abreviar, o se queda sin espacio, y se cansa de escribir nombres de columna tan largos.

2 centavos.

Answer 6

Estoy de acuerdo con @InSane y me gusta solo Id. Y aquí está el porqué:

Si tiene una tabla llamada Usuario y una columna que trata sobre el nombre del usuario, ¿lo llama Nombre de usuario o simplemente Nombre? El "Usuario" parece redundante. Si tiene una tabla llamada Cliente, y una columna llamada Dirección, ¿llama a la columna CustomerAddress?

Aunque también he visto dónde usaría UserId, y luego si tiene una tabla con una clave externa para Usuario, la columna también sería UserId. Esto permite la coherencia en la denominación, pero IMO, no te compra tanto.

Answer 7

OK así que olvidar el ejemplo 3 - es simplemente una tontería, así que es entre 1 y 2.

el id de la escuela PK del pensamiento (2)

drop table if exists customer; 
create table customer 
(
id int unsigned not null auto_increment primary key, -- my names are id, cid, cusid, custid ???? 
name varchar(255) not null 
)engine=innodb; 

insert into customer (name) values ('cust1'),('cust2'); 

drop table if exists orders; 

create table orders 
(
id int unsigned not null auto_increment primary key, -- my names are id, oid, ordid 
cid int unsigned not null -- hmmm what shall i call this ? 
)engine=innodb; 

insert into orders (cid) values (1),(2),(1),(1),(2); 

-- so if i do a simple give me all of the customer orders query we get the following output 

select 
c.id, 
o.id 
from 
customer c 
inner join orders o on c.id = o.cid; 

id id1 -- big fan of column names like id1, id2, id3 : they are sooo descriptive 
== === 
1  1 
2  2 
1  3 
1  4 
2  5 

-- so now i have to alias my columns like so: 

select 
c.id as cid, -- shall i call it cid or custid, customer_id whatever ?? 
o.id as oid 
from 
customer c 
inner join orders o on c.id = o.cid; -- cid here but id in customer - where is my consistency ? 

cid oid 
== === 
1  1 
2  2 
1  3 
1  4 
2  5 

el prefijo tablename_id de Nombre de PK/FK escuela de pensamiento (1)

(no dude en utilizar una forma abreviada de nombre de tabla es decir cust_id en lugar de customer_id)

drop table if exists customer; 
create table customer 
(
cust_id int unsigned not null auto_increment primary key, -- pk 
name varchar(255) not null 
)engine=innodb; 

insert into customer (name) values ('cust1'),('cust2'); 

drop table if exists orders; 
create table orders 
(
order_id int unsigned not null auto_increment primary key, 
cust_id int unsigned not null 
)engine=innodb; 

insert into orders (cust_id) values (1),(2),(1),(1),(2); 

select 
c.cust_id, 
o.order_id 
from 
customer c 
inner join orders o on c.cust_id = o.cust_id; -- ahhhh, cust_id is cust_id is cust_id :) 

cust_id order_id 
======= ======== 
1   1 
2   2 
1   3 
1   4 
2   5 

para que vea el prefijo tablename_ o el método abreviado tablename_prefix es de lo más consistente y es la mejor convención.

Answer 8

ID es el peor nombre de PK que puede tener en mi opinión. TablenameID funciona mucho mejor para los informes, por lo que no tiene que alias un grupo de columnas denominadas lo mismo cuando se realizan complejas consultas de informes.

Creo que las columnas solo se deben nombrar de la misma manera si significan lo mismo. El ID del cliente no significa lo mismo que el ID de pedido y, por lo tanto, deberían tener diferentes nombres conceptualmente. Cuando tiene muchas combinaciones y una estructura de datos compleja, es más fácil de mantener también cuando el pk y el fk tienen el mismo nombre. Es más difícil detectar un error en una combinación cuando tiene columnas de ID. Por ejemplo, supongamos que se unió a cuatro tablas, todas las cuales tienen una columna de ID. En la última unión accidentalmente usaste el alias para la primera tabla y no la tercera. Si usa OrderID, CustomerID etc. en lugar de ID, obtendrá un error de sintaxis porque la primera tabla no contiene esa columna. Si usa ID, felizmente se uniría incorrectamente.

Answer 9

En respuesta a la respuesta de Tomás, todavía habrá ambigüedad suponiendo que el PK por el comentario mesa también se nombra Identificación.

En respuesta a la pregunta, Ejemplo 1 obtiene mi voto. [nombre de la tabla] _id en realidad eliminaría la ambigüedad.

En lugar de

SELECT u.id AS user_id, c.id AS comment_id FROM user u JOIN comment c ON u.id=c.user_id

yo podría simplemente escribir

SELECT user_id, comment_id FROM user u JOIN comment c ON u.user_id=c.user_id

No hay nada ambigua sobre cómo utilizar el mismo nombre de identificación tanto en DONDE y EN. En realidad, agrega claridad en mi humilde opinión.