[Mysql] Una tabella o più tabelle?

[Bukowski]

Salve a tutti,
in questi giorni mi sto dedicando ad un pò di ottimizzazione di vecchi progetti e ho bisogno di levarmi qualche dubbio dalla testa.

Ora, so che in linea di massima si tende ad avere più tabelle per relazionarle tra loro che una unica con una marea di roba dentro (ovviamente dipende).

Ma poniamo il fatto che abbia la tabella utenti fatta cosi:

ID | NICK | PASSWORD | DATA | STATUS | ISCRIZIONE | SESSO | CITTA | NEWSLETTER | AVATAR | CREDITI | ONLINE | LIVELLO | LASTLOGIN

C'è chi consiglierebbe di dividerla, magari, in 2, spostando i dati anagrafici su un'altra tabella.

Ma è davvero così conveniente?

La mia domanda è,
quando faccio una SELECT distinta, in cui richiamo solo dei campi specifici, non è come se quella tabella fosse composta solo da quei campi?

Es. SELECT id, nick, password FROM user

I dati maneggiati dalla mia richiesta non sono gli stessi identici che se avessi avuto una tabella fatta solo di quei campi?

E' così tanto conveniente avere più tabelle "figlie" di un'altra rispetto ad una unica con un tot di campi?

Grazie mille per eventuali delucidazioni.

[optime]

di quante righe stiamo parlando? mille/diecimila o dieci/cento milioni? perché con così pochi campi, dividere la tabella in due avrebbe senso solo con davvero tanti dati.

[Bukowski]

Parliamo di circa 1mln di righe.
Niente di enorme, ma neanche piccolissimo.

Considera che è una tabella che riceve parecchi update, non so se questo è un "problema".

[Bukowski]

Up!

[las]

l'utilità di dividere la tabella secondo me è legata principalmente alla gestione dei dati 1:molti più che alla velocità di esecuzione delle query, nel tuo esempio se un utente ha più di un indirizzo (es. studio e casa) con una tabella singola sei fregato.

Per quanto riguarda la velocità anche qui il problema non è tanto i dati che estrai quanto le condizioni e gli ordinamenti:

SELECT id, nick, password FROM user WHERE nick='pippo'

oppure

SELECT * FROM user WHERE nick='pippo'

deve andare a leggere comunque solo il campo nick anche se la tabella ha altri 2000 campi .... poi è chiaro che se hai veramente 2000 campi e li tiri giù tutti poi avrai un array enorme da gestire e ti rallenta il programma da altre pati .... ma questo è un altro discorso.

comunque in linea di massima io sono per utilizzare più tabelle, ma non per la velocità, ma per poter gestire più dati.

[optime]

direi che ti conviene lasciare la tabella unica perché:
- fai sempre select mirate: tieni presente che se dividi avrai a che fare con le join, quindi perdi in velocità
- fai molti update: nel caso di tabella unica, fai tutto con un'unica istruzione, altrimenti se devi aggiornare colonne in più tabelle devi fare più update
- in fondo, un milione di righe non è tantissimo.

casomai metti gli indici giusti sui campi che ricerchi più frequentemente

[Bukowski]

Sono assolutamente d'accordo con voi, tanto più che uso sempre una tabella ben fatta e ben indicizzata.
Stavo cercando della documentazione che accertasse nello specifico se questo sia il modo migliore di lavorare oppure no, visto che sembra che tutti gli altri amino fare più tabelle e relazionarle tra loro che farne una ma fatta bene.

Da qui il mio dubbio.

[optime]

la questione va analizzata caso per caso, non c'è IMHO una regola che vada bene sempre e comunque

[piero.mac]

Originariamente inviato da Bukowski
Sono assolutamente d'accordo con voi, tanto più che uso sempre una tabella ben fatta e ben indicizzata.
Stavo cercando della documentazione che accertasse nello specifico se questo sia il modo migliore di lavorare oppure no, visto che sembra che tutti gli altri amino fare più tabelle e relazionarle tra loro che farne una ma fatta bene.

Da qui il mio dubbio.

Se i valori che inserisci in una tabella sono atomici ed esclusivi di quel dato record allora si usa una sola tabella.

Se i valori devono essere replicati su piu' record della stessa tabella allora devono essere suddivisi. Prima normalizzazione, seconde e terza....

http://it.wikipedia.org/wiki/Normali...informatica%29
http://www.mrwebmaster.it/sql/artico...se_1004_2.html

inoltre un classico:

http://www.lmgtfy.com/?q=Database+forme+normali#seen

[infinitejustice]

La normalizzazione di una tabella (suddividerla in tabelle linkate fra loro) non è una questione di gusto, ma di necessità di avere dati su cui fare operazioni in maniera consistente.

Ci sono diversi campi che quasi implorano l'esser messi tabelle a parte ed esser referenziati tramite foreign key: città, sesso, livello.

Se avessi 200k utenti di livello X e decidessi semplicemente di cambiargli il nome, dovresti effettuare una operazione sicuramente piu costosa di quella di cambiar un singolo campo in una tabella a parte che associa una id unica ad ogni livello (questa id è foreign key nel campo livello di ogni user).

Come identifichi in maniera univoca un utente? Dall'ID (not null, auto_increment) o dal nick? Due utenti, posson avere lo stesso nick? Se non possono, allora nick sarebbe di per se unico e non ci sarebbe bisogno del campo id...