Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[OT] "Doppia" primary key in mysql
677 views
Skip to first unread message
^Bart
Dec 10, 2018, 12:26:17 PM12/10/18
to
Salve,
sapete meglio di me che i n.g. dedicati a MySQL sono pressochè spariti
quindi posto qui questo [OT] per chiarire un dubbio:
Nome varchar(20),
Cognome varchar(20),
primary key (Cognome,Nome)
Io ho sempre trovato esempi ed ho sempre associato una primary key ad
una singola colonna non a due, quali potrebbero essere gli aspetti
positivi di questo esempio?
Di fatto non è una doppia primary key come virgolettato in oggetto ma
una primary key che contempla due colonne.
Saluti.
^Bart
sapete meglio di me che i n.g. dedicati a MySQL sono pressochè spariti
quindi posto qui questo [OT] per chiarire un dubbio:
Nome varchar(20),
Cognome varchar(20),
primary key (Cognome,Nome)
Io ho sempre trovato esempi ed ho sempre associato una primary key ad
una singola colonna non a due, quali potrebbero essere gli aspetti
positivi di questo esempio?
Di fatto non è una doppia primary key come virgolettato in oggetto ma
una primary key che contempla due colonne.
Saluti.
^Bart
Leonardo Serni
Dec 10, 2018, 12:28:08 PM12/10/18
to
On Mon, 10 Dec 2018 18:26:16 +0100, ^Bart <gabriel...@hotmail.com> wrote:
>Nome varchar(20),
>Cognome varchar(20),
>primary key (Cognome,Nome)
>Io ho sempre trovato esempi ed ho sempre associato una primary key ad
>una singola colonna non a due, quali potrebbero essere gli aspetti
>positivi di questo esempio?
Che non ti serve una colonna in più per la chiave primaria :-)
>Nome varchar(20),
>Cognome varchar(20),
>primary key (Cognome,Nome)
>Io ho sempre trovato esempi ed ho sempre associato una primary key ad
>una singola colonna non a due, quali potrebbero essere gli aspetti
>positivi di questo esempio?
Leonardo
--
"You all presumably know why" :-) :-(
Alessandro Pellizzari
Dec 10, 2018, 1:20:41 PM12/10/18
to
On 10/12/2018 17:26, ^Bart wrote:
> Nome varchar(20),
> Cognome varchar(20),
> primary key (Cognome,Nome)
>
> Io ho sempre trovato esempi ed ho sempre associato una primary key ad
> una singola colonna non a due, quali potrebbero essere gli aspetti
> positivi di questo esempio?
Te ne posso dare uno negativo: non puoi avere omonimi nel DB. :D
> Nome varchar(20),
> Cognome varchar(20),
> primary key (Cognome,Nome)
>
> Io ho sempre trovato esempi ed ho sempre associato una primary key ad
> una singola colonna non a due, quali potrebbero essere gli aspetti
> positivi di questo esempio?
La chiave primaria di un DB è una rogna da decidere. Molti prendono la
via semplice di avere un indice autoincrement (o uno uniqid di qualche
tipo), ma a volte ha più senso risparmiare quello spazio (e la ligica di
calcolare la chiave).
Per esempio, una tabella di connessione contenuto<->tag può avere una
primary key (id_contenuto, tag), senza bisogno di una colonna id auto
increment. Risparmi spazio sulla tabella, eviti un indice da tenere
aggiornato, ecc. In questo caso puoi anche evitare di avere una tabella
con la lista dei tag (a meno che i tuoi tag non siano più lunghi di 700
caratteri :P)
In altri casi, tipicamente quando non hai un set di campi che puoi
definire univoco, la primary key auto increment ha senso.
Bye.
fma...@gmail.com
Dec 10, 2018, 3:15:31 PM12/10/18
to
Chiavi primarie e uniche non sono la stessa cosa. Su una tabella puoi avere
una chiave primaria e varie chiavi uniche.
Il compito di una chiave unica è mettere un vincolo sui dati, in maniera che
il database possa scegliere se accettare o rifiutare l'inserimento o la
modifica di un record (e.g. una email può corrispondere ad un solo utente).
Il compito di una chiave primaria è ottimizzare le ricerche. Cercare per
chiave unica garantisce la massima performance possibile per il DBMS
(e.g. dammi l'utente numero 123).
Per come sono fatti i DB, una chiave primaria è sempre anche unica.
Detto questo, le chiavi primarie possono essere surrogate o naturali.
Le chiavi surrogate sono campi extra che metti nella tabella, ovverso il
famoso ID. E' il metodo più comune di identificare un record dai tempi
preistorici dell'informatica.
Le chiavi naturali sono formate a partire da altri campi della tabella,
nel tuo caso nome e cognome. Pro: non ti serve né ID né campo extra per
avere una ricerca ottima, contro: devi essere sicuro sia una combinazione
unica in ogni caso, e di avere tutti i campi necessari quando fai una
ricerca (e.g. se la chiave è nome/cognome, se hai solo il nome o solo il
cognome la ricerca non è ottima).
Nella pratica, dirai tu?
I DBA preferiscono sempre le chiavi naturali, ma raramente c'è una
combinazione di campi simile nel mondo reale, o comunque tale da avere
la massima performance su ogni possibile query che le applicazioni finali
vogliono fare.
I programmatori di solito mettono solo chiavi surrogate perché in media
o non sanno una cippa di teoria, o non seguono un progetto :)
Ciao!
fma...@gmail.com
Dec 10, 2018, 3:25:48 PM12/10/18
to
On Monday, December 10, 2018 at 3:15:31 PM UTC-5, fma...@gmail.com wrote:
> I DBA preferiscono sempre le chiavi naturali, ma raramente c'è una
> combinazione di campi simile nel mondo reale, o comunque tale da avere
> la massima performance su ogni possibile query che le applicazioni finali
> vogliono fare.
>
Devo aggiungere una cosa perché l'ho pensata ma non l'ho scritta :)
> I DBA preferiscono sempre le chiavi naturali, ma raramente c'è una
> combinazione di campi simile nel mondo reale, o comunque tale da avere
> la massima performance su ogni possibile query che le applicazioni finali
> vogliono fare.
>
Ci sono anche chiavi non primarie e non uniche. Puoi avere una tabella con
una chiave primaria naturale, e varie chiavi non uniche ideate solo per
qualche query. In questo modo puoi scegliere di avere una base di dati
il più "naturale" possibile, e non pesare troppo sulle performance (non
entro nei dettagli specifici perché poi serve una base di algoritmi su
alberi e un'idea sulle performances di due tipi diversi di cache - chi è
curioso e non ha voglia di cercare magari può chiedere ;)).
Ciao!
bramante
Dec 10, 2018, 4:10:40 PM12/10/18
to
Il 10/12/18 21:25, fma...@gmail.com ha scritto:
in quel caso non metterei delle constraint ma degli indici, se cerco
delle performance poi a seconda dei tipo di indice e su quale campo
sceglierei l'indice più adatto (hash, btree,rtree ecc)
avere troppi indici equivale a non averne, questo è una delle massime
che ho imparato con l'esperienza.
Ciao
delle performance poi a seconda dei tipo di indice e su quale campo
sceglierei l'indice più adatto (hash, btree,rtree ecc)
avere troppi indici equivale a non averne, questo è una delle massime
che ho imparato con l'esperienza.
Ciao
fma...@gmail.com
Dec 10, 2018, 4:26:33 PM12/10/18
to
On Monday, December 10, 2018 at 4:10:40 PM UTC-5, bramante wrote:
> avere troppi indici equivale a non averne, questo è una delle massime
> che ho imparato con l'esperienza.
>
??
> avere troppi indici equivale a non averne, questo è una delle massime
> che ho imparato con l'esperienza.
>
Hai imparato male, allora :)
A meno che non ti riferisci, a parte le ricerche, al tempo necessario a
fare insert e update, che naturalmente rallentano, e che sicuramente in
certi casi sono molto più importanti delle select - e non abbiamo ancora
parlato dello spazio su disco, che a volte non è indifferente.
Ma qui si rientra su un campo ben più pratico, quello di sforzarsi di fare
profiling prima di prendere scelte del genere: prima si misura, puoi si
mettono le chiavi.
Ma la premature optimization è un problema psicologico più che pratico ;)
Rimango dell'idea che un DB debba essere il più naturale possibile (i.e.
niente chiavi surrogate, anzi, di nessun tipo, a parte i constraint) e, in
caso di problemi *seri* sulle performances, ottimizzato all'occorrenza.
Ciao!
bramante
Dec 10, 2018, 4:59:57 PM12/10/18
to
Il 10/12/18 22:26, fma...@gmail.com ha scritto:
mi riferisco, non solo all'incremento di tempo per fare
insert/update/delete, ma all'uso stravagante che ho visto fare in query
complesse, dove per "tentare" di migliorare le performance si è voluto
aggiungere indici dove non servivano, invece di analizzare come era
scritta la query,
poi mettici anche che avere più indici e andare ad "interrogarli"
contemporaneamente insieme con campi di altre tabelle non indicizzate
nelle join in full table scan ed in prodotto cartesiano.
nella mente dello sviluppatore si voleva estrarre una matrice
gennaio-dicembre (colonne) da 1 a 31 (le righe in giorni) facendo pivot
di tabelle contenenti dati (da elaborare) dove uno dei campi era la data
(che doveva identificare dove piazzare il risultato della query
all'interno della matrice)
un accozzaglia di tonnellate di istruzioni sql senza capo ne coda.
Ciao
insert/update/delete, ma all'uso stravagante che ho visto fare in query
complesse, dove per "tentare" di migliorare le performance si è voluto
aggiungere indici dove non servivano, invece di analizzare come era
scritta la query,
poi mettici anche che avere più indici e andare ad "interrogarli"
contemporaneamente insieme con campi di altre tabelle non indicizzate
nelle join in full table scan ed in prodotto cartesiano.
nella mente dello sviluppatore si voleva estrarre una matrice
gennaio-dicembre (colonne) da 1 a 31 (le righe in giorni) facendo pivot
di tabelle contenenti dati (da elaborare) dove uno dei campi era la data
(che doveva identificare dove piazzare il risultato della query
all'interno della matrice)
un accozzaglia di tonnellate di istruzioni sql senza capo ne coda.
Ciao
fma...@gmail.com
Dec 10, 2018, 5:08:13 PM12/10/18
to
On Monday, December 10, 2018 at 4:59:57 PM UTC-5, bramante wrote:
> Il 10/12/18 22:26, fma...@gmail.com ha scritto:
> > <snip>
> Il 10/12/18 22:26, fma...@gmail.com ha scritto:
> >
> mi riferisco, non solo all'incremento di tempo per fare
> insert/update/delete, ma all'uso stravagante che ho visto fare in query
> complesse, dove per "tentare" di migliorare le performance si è voluto
> aggiungere indici dove non servivano, invece di analizzare come era
> scritta la query,
>
> poi mettici anche che avere più indici e andare ad "interrogarli"
> contemporaneamente insieme con campi di altre tabelle non indicizzate
> nelle join in full table scan ed in prodotto cartesiano.
>
> nella mente dello sviluppatore si voleva estrarre una matrice
> gennaio-dicembre (colonne) da 1 a 31 (le righe in giorni) facendo pivot
> di tabelle contenenti dati (da elaborare) dove uno dei campi era la data
> (che doveva identificare dove piazzare il risultato della query
> all'interno della matrice)
>
> un accozzaglia di tonnellate di istruzioni sql senza capo ne coda.
>
Ah, chi non sa cosa fa, fa casino in qualsiasi situazione, non solo sui
> mi riferisco, non solo all'incremento di tempo per fare
> insert/update/delete, ma all'uso stravagante che ho visto fare in query
> complesse, dove per "tentare" di migliorare le performance si è voluto
> aggiungere indici dove non servivano, invece di analizzare come era
> scritta la query,
>
> poi mettici anche che avere più indici e andare ad "interrogarli"
> contemporaneamente insieme con campi di altre tabelle non indicizzate
> nelle join in full table scan ed in prodotto cartesiano.
>
> nella mente dello sviluppatore si voleva estrarre una matrice
> gennaio-dicembre (colonne) da 1 a 31 (le righe in giorni) facendo pivot
> di tabelle contenenti dati (da elaborare) dove uno dei campi era la data
> (che doveva identificare dove piazzare il risultato della query
> all'interno della matrice)
>
> un accozzaglia di tonnellate di istruzioni sql senza capo ne coda.
>
database! :D
Però anche qui, preferisco avere una struttura teoricamente ideale e
correggere chi sbaglia, invece di una struttura foolproof che è subottima
per quasi ogni caso.
Ma questo discorso è ancora diverso, si parlerebbe di modelli di business :)
Ciao!
0 new messages