Progettazione database - convenzioni di denominazione delle chiavi primarie

Question

Sono interessato a sapere cosa pensano le persone (E PERCHÉ) le seguenti 3 convenzioni diverse per denominare le chiavi primarie della tabella di database in MySQL?

-Example 1-

Tabella Nome: utente,
nome della colonna chiave primaria: ID_utente

-Example 2-

Tabella Nome: utente,
nome della colonna chiave primaria: id

-Esempio 3-

Nome tabella: U ser,
principale nome colonna chiave: pk_user_id

Voglio solo sentire le idee e magari imparare qualcosa nel processo :)

Grazie.

Answer 1

Ho sempre apprezzato l'approccio di Justinsomnia alle convenzioni di denominazione dei database. Dategli una lettura: http://justinsomnia.org/2003/04/essential-database-naming-conventions-and-style/

Answer 2

Vorrei suggerire esempio 2. In questo modo non v'è alcuna ambiguità tra chiavi esterne e chiavi primarie, in quanto v'è nell'esempio 1. Si può fare, per esempio

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

che è chiaro e conciso.

Il terzo esempio è ridondante in un progetto in cui tutti gli ID vengono utilizzati come chiavi primarie.

Answer 3

Vorrei andare con l'opzione 2. Per me, "id" sembra abbastanza sufficiente. Poiché la tabella è Utente, quindi la colonna "id" in "utente" indica che si tratta dei criteri di identificazione per Utente.

Tuttavia, devo aggiungere che le convenzioni di denominazione sono tutte basate sulla coerenza. Di solito non c'è giusto/sbagliato finché c'è un modello coerente e viene applicato attraverso l'applicazione, questo è probabilmente il fattore più importante in quanto l'efficacia delle convenzioni di denominazione sarà e quanto sono lontani per rendere l'applicazione più facile da capire e quindi mantenere.

Answer 4

Preferisco sempre l'opzione nell'esempio 1, in cui il nome della tabella è (ridondante) utilizzato nel nome della colonna. Questo perché preferisco vedere ON user.user_id = history.user_id rispetto a ON user.id = history.user_id in JOINs.

Tuttavia, il peso di parere su questo tema in generale sembra funzionare contro di me qui in StackOverflow, dove la maggior parte delle persone preferisce esempio 2.

Per inciso, io preferisco UserID a ID_utente come convenzione di denominazione di colonna. Non mi piace digitare caratteri di sottolineatura, e l'uso del carattere di sottolineatura come carattere di corrispondenza a singolo carattere SQL comune può a volte essere un po 'di confusione.

Answer 5

Tendo ad andare con la prima opzione, user_id.

Se si utilizza id, in genere si finisce con la necessità di eseguire un alias eccessivo nelle query. Se si utilizza more_complicated_id, è necessario abbreviare o esaurire la stanza e ci si stanca di digitare nomi di colonne così lunghi.

2 centesimi.

Answer 6

Sono d'accordo con @InSane e mi piace solo Id. Ed ecco perché:

Se si dispone di una tabella denominata Utente e una colonna si occupa del nome dell'utente, si chiama UserName o solo Nome? "Utente" sembra ridondante. Se si ha una tabella denominata Cliente e una colonna denominata Indirizzo, si chiama la colonna Indirizzo cliente?

Anche se ho visto anche dove si utilizza UserId e quindi se si dispone di una tabella con una chiave esterna per Utente, la colonna sarebbe anche UserId. Ciò consente la coerenza nella denominazione, ma IMO, non ti compra così tanto.

Answer 7

OK in modo da dimenticare esempio 3 - è semplicemente stupido, quindi è tra 1 e 2.

l'id per la scuola PK di pensiero (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 

il prefisso tablename_id per PK/FK nome scuola di pensiero (1)

(non esitate a utilizzare una forma abbreviata di tablename vale a dire cust_id invece di customerid)

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 

in modo da vedere il prefisso tablename_ o il metodo tablename_prefix abbreviato è OFC il più coerente e facilmente il migliore convenzione.

Answer 8

ID è il peggior nome PK che puoi avere a mio parere. TablenameID funziona molto meglio per la creazione di report in modo da non dover creare alias un gruppo di colonne denominate la stessa cosa quando si eseguono query di report complesse.

È mia convinzione personale che le colonne debbano essere nominate la stessa cosa se significano la stessa cosa. L'ID cliente non significa la stessa cosa dell'ordinamento e quindi dovrebbero concettualmente avere nomi diversi. Quando si hanno molti join e una struttura di dati complessa, è più facile da mantenere anche quando pk e fk hanno lo stesso nome. È più difficile individuare un errore in un join quando si dispone di colonne ID. Ad esempio, supponiamo di aver aderito a quattro tabelle che hanno tutte una colonna ID. Nell'ultimo join hai usato per errore l'alias per il primo tavolo e non il terzo. Se hai usato OrderID, CustomerID ecc. Anziché ID, si otterrebbe un errore di sintassi perché la prima tabella non contiene quella colonna. Se usi l'ID, si unirebbe felicemente.

Answer 9

In risposta alla risposta Tomas', ci saranno ancora ambiguità supponendo che la PK per il commento tavolo è anche il nome id.

In risposta alla domanda, Esempio 1 ottiene il mio voto. [nome tabella] _id rimuoverebbe effettivamente l'ambiguità.

Invece di

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

Potrei scrivere semplicemente

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

Non c'è nulla di ambiguo utilizzando lo stesso nome ID sia DOVE e ON. In realtà aggiunge chiarezza IMHO.