Provo ad esporti quelle che sono state le scelte che mi hanno portato ad optare per questa soluzione.
Il sistema è una sorta di community suddivisa in categorie e sottocategorie. Ogni sottocategoria conterrà degli annunci, mentre la categoria sarà solo un contenitore di sottocategorie.
Ogni annuncio sarà composto massimo da N campi e ogni categoria sarà composta da un subset di questi N campi: quindi avranno tutte dei campi comuni.
L'idea iniziale era quella di creare un'unica tabella per contenere gli annunci aggiungendo un campo per distinguere la categoria cui apparteneva l'annuncio.
Questa soluzione a mio avviso aveva due svantaggi:
1 - Nel caso di una categoria che non utilizzasse tutti i campi molti sarebbero sempre rimasti vuoti con uno spreco di spazio;
2 - Nell'ottica di popolamento di massa delle community quest'unica tabella degli annunci avrebbe raggiunto dimensioni considerevoli con probabili estremi rallentamenti nelle operazioni di ricerca.
Alla fine ho optato per la realizzazione di una tabella per ogni sottocategoria.
Da notare che le sottocategorie di una stessa categoria sono tutte composte dagli stessi campi: avrei quindi potuto optare per la creazione di un'unica tabella per ogni categoria ma temevo il possibile problema numero 2, ossia tabella enorme e lenta.
Questa soluzione si rivela performante per ricerche all'interno della specifica sottocategoria ma richiedeva un numero enorme di query con UNION per le ricerche all'interno di una sottocategoria: da qui la scelta di optare per l'utilizzo delle viste che si semplificano il numero di query e la loro sintassi ma che hanno quel problema di lentezza alla prima esecuzione.
Sicuramente questo database non è "normalizzato" ma mi sembrava la soluzione più performante: qualche idea?