Consiglio x DB mysql: meglio maxi tabellona o mini tabelline?

[lyllo]

ciao gente.
ai fini di prestazioni, sovraccarico del server, rischio di crash, è meglio suddividere il proprio database in sotto-tabelline linkate o una bella maxi tabella?
sto parlando ovviamente di dati tutti conformi.
nel senso che immaginiamo di avere una tabella "utenti" che contenga 40 campi.
tutti e 40 i campi sono pertinenti a quella stessa tabella nome, cognome, indirizzo, CF, PIVA, esami del sangue), ma nel contempo possono essere raggruppati in sotto-tabelle tutte linkate con l'id_utente (tab_analisi, tab_fisco etc.)
cos'è meglio?

grazie.

[bubu77]

non esiste un metodo scientifico ma si deve valutare caso per caso

il codice fiscale ad esempio è un campo unico per anagrafica è viene usato spesso per cercare un cliente quindi meglio tenerlo nella tabella principale

i recapiti al contrario si prestano molto ad essere intabellati per conto suo invece di avere email, email2, email3, tel1, tel2, tel3 ecc ecc che renderebbero la tabella principale ingestibile

quindi valgono le regole di sempre, se i dati sono 1 a 1 la tabella è la solita, se sono 1 a n meglio intabellare

ciao

[lyllo]

eh io appunto di valutare caso per caso sto chiedendo..
non rispondere sul testo della tabella, perchè non sono quelli i campi, era solo per fare un esempio.

quello che voglio dire è che i campi sono coerenti e possono stare, a logica, sia in un'unica tabella che in tabelle multiple.
a me interessa sapere se è meglio suddividerle per evitare che ad ogni query si debba fare un fetch di un array di 40 campi tutti in blocco, oppure se la suddivisione in sotto-tabelle possa poi rendere la query più pesante, una volta che dovesse servire fare più join?

grazie

[LeaderGL]

come ha detto bubu77 dipende da caso a caso....se non prendiamo in esame i dati che ci hai fornito parliamo di fave...

In linea generale puoi avere tabelle come ti pare ma se su 40 attributi (è così che si chiamano) sai che c'è un'alta percentuale che molti di essi rimangano vuoti allora è meglio scorporarli dalla tabella.

Esempio:
TABELLA CLIENTE
ID - CODICEFISCALE - NOME - COGNOME - ESAME_SANGUE - NUMERO_DI_CAPELLI

se sai che "ESAME_SANGUE" non sarà quasi mai valorizzato allora toglilo...è inutile tenerlo lì.

Ma questo non è l'unico fattore, xkè se poi in ogni query che fai sul cliente ti serve sapere il valore di "ESAME_SANGUE" se lo scorpori sarai costretto o a fare 2 query invece di una o a farne una sola ma con una JOIN.

Ovviamente i parametri non sono solo questi, quindi alla tua domanda senza IL TUO CASO PARTICOLARE non c'è risposta.

[lyllo]

si in realtà ero giunto ad una conclusione simile a quella di cui hai parlato: ho pensato di valutare quali sarebbero i campi (mi suona strano definire attributo un campo di una tabella) più utilizzati in determinate aree del sito e dunque suddividere la tabella in modo da richiamare solo la sotto-tabella interessata.

in linea di massima, cmq, una JOIN costa di più di una query semplice?

[rasega]

Secondo me in ogni caso servono almeno un paio di tabelle,
alcuni dati tipo quelli anagrafici sono costanti e rischierebbero di ripetersi continuamente (lo stesso utente fa più esami del sangue), quindi nel caso di singola tabella la quantità di dati sarebbe certamente maggiore nel caso 1 o molti !!

Per verificare la lentezza di una JOIN rispetto ad una query normale provale direttamente in mysql e vedi il tempo di risposta

[lyllo]

ok grazie.
non mi ricordo se c'era una classe scaricabile in rete o direttamente una funzione php5 per fare il benchmark?

[rasega]

Questo non saprei, io intendevo di vederlo direttamente dal phpmyadmin,
dovrebbe darti i tempi di risposta delle query !!

[lyllo]

Originariamente inviato da rasega
Questo non saprei, io intendevo di vederlo direttamente dal phpmyadmin,
dovrebbe darti i tempi di risposta delle query !!

azz giusto, much more smart! che fagggiano che so! grazie