(mysql) Tabella con 2 chiavi (prestazioni nelle select)

[Kahm]

salve a tutti
dovrei create una tabella in sqlserver, dove ragionando logicamente i campi immesso hanno un codicefiscale,data e codiceTransazione univocuo, sarebbe quindi logico mettere una tabella con 3 chiavi...cioè l'unione di Codicefiscale,data e CodiceTransazione

ma proprio su questo punto ho avuto un dubbio
ebbene,si sa benissimo che facendo le select in un database, piu aumentano le "AND" e piu' si è a rischio rallentamenti
secondo voi potrei benissimo mettere un campo contatore e fare in modo di filtrare i dati per un unico campo?

questo dubbio mi è pervenuto leggendo i suggerimenti microsoft sui database

qualche spiegazione?
grazie

[piero.mac]

una chiave primaria ottimale deve essere semplice, formata dallo stesso tipo di valore (es. numerico), di lunghezza fissa, senza mixer maiuscole/minuscole, da non modificare, mai NULL, senza riferimento al contenuto della tupla, ecc.....

Ecco qui il suggerimento di usare un contatore (es. un id autoincrement) perche' rimane "sempre" la soluzione ottimale per una chiave primaria. Nulla vieta di raggruppare in un indice UNIQUE piu' campi che si desiderano non possano essere mai duplicati.

[Kahm]

uhmmm boh
io avevo proprio messo una tabella con un campo contatore
ma il mio capo mi ha rimproverato proprio per questo

logicamente nella tabella poteva esserci un codicecliente unito ad un solo ordine, io per semplificare ho messo un contatore, ma lui ha voluto fare una doppia chiave:codicecliente+codiceOrdine
dicendo che è logicamente corretto e poi il contatore ha un limite

ritornando a casa mi sono venuti molti dubbi, primo fra tutti proprio quello delle prestazioni per fare la select, e secondo dover gestire 2 campi in ogni cosa!

puoi darmi ulteriori spiegazioni in merito?
grazie

[piero.mac]

Premesso che in questi casi e' meglio attaccare il carretto dove vuole l'asino....

le cose sono come ti ho detto prima. Una chiave primaria "ottimale" ha determinate caratteriste sopra gia' elencate. Poi qualunque campo "univoco" e non NULL puo' essere utilizzato come chiave primaria. Compreso gruppi di campi ovviamente.

Sinceramente non mi sono mai sfiatato per fare le cose diverse da quanto preteso da chi commissiona un lavoro. Al limite una nota nelle rem.... tabella ottimizzata secondo le precise richieste di Nome e Cognome.

In altre parole.... la richiesta non e' formalmente errata, ma non e' una tabella ottimizzata secondo i canoni standard. Quello che si risparmia con una colonna in meno lo si perdera' con un indice piu' voluminoso e con un maggior uso di risorse.