Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #22413 > unrolled thread

[OT] "Doppia" primary key in mysql

Back to article view | Back to it.comp.www.php

Contents

  [OT] "Doppia" primary key in mysql ^Bart <gabriele1NOSPAM@hotmail.com> - 2018-12-10 18:26 +0100
    Re: [OT] "Doppia" primary key in mysql Leonardo Serni <lserni@gmail.com> - 2018-12-10 18:28 +0100
    Re: [OT] "Doppia" primary key in mysql Alessandro Pellizzari <shuriken@amiran.it> - 2018-12-10 18:20 +0000
    Re: [OT] "Doppia" primary key in mysql fmassei@gmail.com - 2018-12-10 12:15 -0800
      Re: [OT] "Doppia" primary key in mysql fmassei@gmail.com - 2018-12-10 12:25 -0800
        Re: [OT] "Doppia" primary key in mysql bramante <bramante@yopmail.com> - 2018-12-10 22:10 +0100
          Re: [OT] "Doppia" primary key in mysql fmassei@gmail.com - 2018-12-10 13:26 -0800
            Re: [OT] "Doppia" primary key in mysql bramante <bramante@yopmail.com> - 2018-12-10 22:59 +0100
              Re: [OT] "Doppia" primary key in mysql fmassei@gmail.com - 2018-12-10 14:08 -0800

#22413 — [OT] "Doppia" primary key in mysql

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

[toc] | [next] | [standalone]

#22414

On Mon, 10 Dec 2018 18:26:16 +0100, ^Bart <gabriele1NOSPAM@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 :-)

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#22415

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

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.

[toc] | [prev] | [next] | [standalone]

#22416

On Monday, December 10, 2018 at 12:26:17 PM UTC-5, ^Bart wrote:
> 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.
> 


Due cose di teoria dei database che magari non sai.

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!

[toc] | [prev] | [next] | [standalone]

#22417

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 :)

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!

[toc] | [prev] | [next] | [standalone]

#22418

Il 10/12/18 21:25, fmassei@gmail.com ha scritto:
> 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 :)
> 
> 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!
> 

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

[toc] | [prev] | [next] | [standalone]

#22419

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.
> 

??
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!

[toc] | [prev] | [next] | [standalone]

#22420

Il 10/12/18 22:26, fmassei@gmail.com ha scritto:
> 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.
>>
> 
> ??
> 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!
> 

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

[toc] | [prev] | [next] | [standalone]

#22421

On Monday, December 10, 2018 at 4:59:57 PM UTC-5, bramante wrote:
> Il 10/12/18 22:26, fmassei@gmail.com ha scritto:
> > <snip>
> > 
> 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
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!

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web