Originariamente inviato da biamat
Sto progettando un database per gestire una community e ho alcuni dubbi riguardo la struttura dello stesso nel caso in cui alcune delle tabelle inizino ad essere molto popolate.
Il sistema dovrebbe gestire un classico sito di annunci suddiviso in categorie. Ogni annuncio avrebbe gli stessi campi indipendentemente dalla categoria di appartenenza: avevo quindi pensato di creare un'unica tabella contenente gli annunci con l'aggiunta del campo categoria_id per definire la categoria di appartenenza dell'annuncio.
Mi sono sorti però dei dubbi riguardo questa struttura che mi sembrava inizialmente la più logica e corretta.
Non ponendomi limiti mi sono chiesto: cosa succederebbe se la tabella annunci fosse popolata con decine di milioni di righe o semplicemente con qualche milione di righe? Probabilmente ci sarebbe un decadimento prestazionale notevole.
Allora ho pensato ad una seconda soluzione: creare una tabella annunci separata per ogni categoria. Si tratterebbe di N tabelle identiche.
Ovviamente effettuando interrogazioni sugli annunci di una singola categoria il tutto dovrebbe essere più veloce ma nelle eventuali sezioni in cui si effettuassero interrogazioni generali riguardanti tutte le categorie contemporanemente dovrei ricorrerre a UNION sulle N tabelle o alla generazione di una vista.
Ho effettuato dei test appunto utilizzando le viste e mi sono accorto che in una situazione come quella appena descritta ci sono evidenti limiti prestazionali.
In difinitiva quello che mi interesserebbe sapere è: esistono dei limiti teorici per le dimensioni delle tabelle oltre le quali conviene ricorrere a soluzioni alternative? Se si, quali potrebbero essere?
So di essere stato un po' vago ma spero di riuscire comunque a trovare l'aiuto di qualcuno per fare un po' chiarezza.
Rispondi quotando
