Utilità chiave primaria in tabella relazioni molti-a-molti

[emanueledg]

Ciao,
in una relazione molti-a-molti, nella tabella che contiene solo le relazioni c'è qualche utilità nell'inserire anche un campo per la chiave primaria autoincrementale?

[piero.mac]

Originariamente inviato da emanueledg
Ciao,
in una relazione molti-a-molti, nella tabella che contiene solo le relazioni c'è qualche utilità nell'inserire anche un campo per la chiave primaria autoincrementale?

mi chiedo invece se e' di qualche utilita' una relazione molti-a-molti.

se hai una tabella che contiene le relazioni significa che NON hai una relazione di tal tipo. Poi un id che identifichi in modo univoco uno specifico record e' sempre auspicabile indifferentemente dal contenuto della tabella stessa.

Insomma, la funzione dell'id e' identificare uno specifico record. Vedi tu...

[bubi1]

Originariamente inviato da emanueledg
Ciao,
in una relazione molti-a-molti, nella tabella che contiene solo le relazioni c'è qualche utilità nell'inserire anche un campo per la chiave primaria autoincrementale?

Non necessariamente. Dipende tutto dal designo logico del database. Pero' una chiave che identifichi in un modo univoco una riga serve sempre.
Nel tuo caso, se le accoppiate sono uniche, l'indice primary lo puoi creare su 2 colonne esistenti, senza dover aggiungerne una apposita.

[bubi1]

Originariamente inviato da piero.mac
mi chiedo invece se e' di qualche utilita' una relazione molti-a-molti.

Esempio reale: Un blog, con la tabella posts e la tabella tags. E poi con la tabella posts_tags - con i campi: post_id e tag_id, per relazionare i tag ai post. Questa e' una relazione molti-a-molti utile
E in qusto esempio specifico, non serve necessariamente il campo id, basta mettere una primary key su post_id e tag_id insieme.

[luca200]

Originariamente inviato da piero.mac
mi chiedo invece se e' di qualche utilita' una relazione molti-a-molti.

[piero.mac]

Originariamente inviato da luca200

Quella era una battuta ....

Comunque: due tabelle relazionate da una tabella di unione non sono in relazione tra di loro, ma con la tabella di unione dove non si "dovrebbe" mai verificare una unione diretta molti a molti tra tab_a e tab_b.

tab_a 1 record pippo
tab_unione tanti record pippo <-> pallino
tab_b 1 record pallino

Ora se la domanda era se ha senso un id per la tabella unione, ebbene si, ne ha ed anche molto

A meno che per molti a molti si intendano cose che non conosco. Del che mi scuso.

[luca200]

Originariamente inviato da piero.mac
Quella era una battuta ....

Comunque: due tabelle relazionate da una tabella di unione non sono in relazione tra di loro, ma con la tabella di unione dove non si "dovrebbe" mai verificare una unione diretta molti a molti tra tab_a e tab_b.

Ah, ok

[emanueledg]

Sì, si tratta di una relazione che intercorre tra due insiemi logici, cioè due tabelle, che viene scritta in una terza tabella di relazioni, contenente solo due campi salienti, ovvero la chiave primaria della prima tabella e quella della seconda.

Io finora ho sempre usato una chiave primaria autoincrementale anche per la tabella di relazione, ma ieri ho visto un script in cui non veniva creata alcuna chiave primaria.
Mi sono innanzitutto interrogato sul funzionamento, e non ho trovato motivi per cui non dovrebbe funzionare.
Le operazioni chiave sono l'inserimento e la lettura, in rari casi anche la modifica e la cancellazione, tuttavia ognuna di queste operazioni viene fatta in base ad uno o più dati dei due insiemi logici in relazione, per cui non viene mai direttamente usato l'indice della tabella di relazione.

Tempo fa (molto) ne parlavi anche tu Piero in un post in cui spiegavi la normalizzazione a qualcuno, dicendo che tra i tipi di relazione quella tanti-a-tanti è quella più "ammazza prestazioni", non ricordo se ti riferivi ad essa chiamandola tanti a tanti ma il significato era quello

Proprio per il fatto che è una situazione ammazza-prestazioni io mi chiedevo se convenisse, oltre ad aver ottimizzato ogni singola vite e bullone del contorno, agire anche sulla tabella di relazione, facendo un piccolo taglio (lo spazio di memoria occupato dai byte della chiave primaria).

Oggi pomeriggio per un'operazione di amministrazione su quella tabella:

DELETE FROM tbl WHERE id > 550;

dove 550 indicava i record di test inseriti per una simulazione... Per cui ho pensato che magari c'è sempre un'utilità che giustifica il piccolo peso in più, solo mi interrogavo su costi e benefici.

[piero.mac]

una tabella senza chiave primaria e' come un tampax senza la cordicella. Funziona lo stesso.

se lo scopo della tabella di unione e' di unire in "MODO UNIVOCO" due tabelle eliminando cosi' la relazione molti a molti, a volte molto difficile da gestire, allora puoi anche farne a meno di una chiave primaria. Ma se tu hai piu' record con la stessa unione allora diventa molto poco probabile tu possa cancellare esattamente "QUEL" record. Tieni presente che nella quasi totalita' dei casi tu potresti avere delle unioni con date differenti o codici (es.: fatturazione) o una descrizione. Ora dimmi come fai ad individuare un record preciso con gli stessi id di riferimento e senza una chiave primaria.

Il "credo" dice che la chiave primaria serve ad individuare esattamente una precisa tupla. Amen.

[emanueledg]

Giusta osservazione, nel caso di record che identifichino la stessa unione, l'id della relazione sarebbe l'unico discriminante, utile per identificare la riga esatta.

Grazie egregi colleghi, è sempre un piacere confrontarsi con voi.