È necessario creare un database con il minor numero di tabelle possibile

Dovremmo creare una struttura di database con un numero minimo di tabelle?

Dovrebbe essere progettato in modo tale che tutto rimanga in un posto o va bene avere più tavoli?

In qualche modo influenzerà qualcosa?

Sto ponendo questa domanda perché un mio amico ha modificato la struttura del database in mediaWiki. Alla fine, invece di 20 tavoli, ne usava solo 8 e gli ci vollero 8 mesi per farlo (era il suo incarico universitario).

MODIFICARE

Concludo la risposta in quanto: le dimensioni delle tabelle NON contano, fino a quando il caso non è eccezionale; nel qual caso la denormalizzazione può aiutare.

Grazie a tutti per le risposte.

IGNORA il numero di tabelle. Preoccupati di più per ottenere il design corretto. Se la tua principale preoccupazione è la quantità di tabelle, probabilmente non dovresti progettare sistemi di database.

Se il tuo amico aveva bisogno solo di 8 tabelle e il sistema funziona bene, allora 8 è il numero corretto e i restanti 12 potrebbero non essere stati necessari per qualsiasi cosa stesse facendo.

Eventuali eccezioni potrebbero essere ambienti peculiari che hanno limiti concreti sui numeri di tabella, ma non riesco a pensare a un esempio concreto di un tale sistema dalla cima della mia testa.

Un database dovrebbe avere esattamente tutte le tabelle di cui ha bisogno. Niente di meno, niente di più.

Le tabelle del database devono aderire al principio di responsabilità singola, proprio come dovrebbero le classi. Ogni tabella dovrebbe trattare non più di un gruppo di dati correlati per cominciare. Prestazioni a parte, questo rende l'intera bestia più facile da gestire, perché i tavoli stessi saranno più piccoli. Questo ti dà anche prestazioni migliori, perché le tabelle più piccole sono più veloci per la ricerca e l'unione.

Non preoccuparti del numero di tabelle più di quanto ti preoccupi per il numero di classi - non preoccuparti affatto. Concentrati sulla creazione di codice valido, pulito e leggibile, non su quanto spazio occupa. Rifattorizza in modo aggressivo una volta che hai un prodotto funzionante per renderlo migliore, e intendo anche il database! Vedrai colonne che dovrebbero trovarsi in altre tabelle, o che non sono necessarie, ecc. Profilo per vedere quali query impiegano più tempo e perché e come affrontare tali problemi se sono davvero un problema.

Un database di produzione per un'applicazione aziendale può contenere centinaia o addirittura migliaia di tabelle. È necessario il numero di tabelle necessarie per i requisiti aziendali. Cercare di ridurre il numero di tabelle solo per avere meno tabelle di solito si tradurrà in un database che è più difficile da interrogare, ha problemi di integrità dei dati ed è molto più difficile da mantenere rispetto a un database normalizzato.

Ci sono momenti in cui è necessaria la denormalizzazione. Questo dovrebbe essere fatto solo da qualcuno che sa esattamente cosa sta facendo e perché. È molto semplice inventare denomalizzazione, quindi dovrebbe essere fatto solo da uno specialista di database o da uno sviluppatore di applicazioni senior con anni di esperienza nel database. Una persona inesperta dovrebbe sforzarsi di raggiungere almeno la terza forma normale (a meno che non si stia facendo un data warehousing che è un'area per la quale non prenderei in considerazione l'assunzione di una persona inesperta) in qualsiasi database che progetta.

Quando la gente dice di ridurre le tabelle perché i join sono costosi, generalmente sono ignoranti o hanno database mal progettati che mancano di indici critici o usano chiavi naturali di grandi dimensioni. I database relazionali sono progettati per utilizzare join e join possono essere abbastanza efficienti se gli FK sono correttamente indicizzati e usano piccoli campi su cui unire (gli interi sono i più efficienti). Noterai che le grandi aziende che dispongono di database di dimensioni terrabyte riescono in qualche modo a ottenere prestazioni eccellenti e utilizzare i join.

Nessun progettista di database serio cerca mai di ridurre il numero di tabelle solo perché desidera un numero inferiore di tabelle. Riduci il numero di tabelle perché i dati non sono più necessari o hai un problema di prestazioni che non puoi risolvere in altro modo (e ci sono molti modi per provare prima di correre il rischio estensivo per i tuoi dati di denormalizzare una tabella) .

Poiché ogni campo in un database è definito dalla combinazione di nome tabella, nome colonna, chiave primaria e valore, è sempre possibile ridurre il numero di tabelle denormalizzando in una singola tabella che memorizza proprio quello. Non molto utile, ma del tutto possibile.

Le tabelle sono un livello astratto che aiuta a risolvere i problemi relativi alla gestione dei dati. Ecco perché sono stati creati. Ho fatto uno scherzo, ma capire che è possibile ridurre ogni serie di dati a una tabella principale indica immediatamente perché non dovresti: perché le tabelle ti portano qualcosa. A livello concettuale ti offrono una struttura che è più facile da capire per gli umani rispetto ai dati serializzati. A livello intermedio portano il concetto di normalizzazione: evitare il salvataggio di dati ridondanti e dare un unico punto per le modifiche, piuttosto che cambiare qualcosa in più punti. A livello tecnico i database portano la maggior parte delle cose che vuoi fare con i dati, numerosi strumenti e li hanno implementati e testati più di quanto probabilmente farai da solo. Pensa a tipi di dati, valori predefiniti, diritti utente, indici, vincoli di chiave esterna ecc. È stato testato, utilizzato da molti, ottimizzato, sottoposto a debug. (Non nella perfezione, ma comunque.)

Poiché un database è uno strumento, la cosa principale è decidere come utilizzare lo strumento. Il numero di tabelle non è importante. Ridurre al minimo è sempre possibile ma a scapito dei vantaggi. (Se leggi di più sulla normalizzazione, ti imbatterai nei pochi casi di denormalizzazione - ma anche in questo caso si tratta solo delle decisioni giuste piuttosto che ridurre ciecamente il numero di tabelle.)

Dovresti usare il giusto numero di tabelle. In teoria si potrebbe accontentarsi di una singola tabella di tabella denormalizzando l'intero database, ma il database sarebbe inutilizzabile. Il tuo amico sembra che abbia troppo tempo a disposizione.

Avere il numero minimo di tavoli mi sembra un obiettivo molto particolare.

Certamente ridurre uno schema da 20 tabelle a 8 potrebbe essere una buona cosa (se fatto bene potrebbe ridurre i join e aumentare le prestazioni, rimuovere colonne inutilizzate e così via) ma potrebbe anche rendere più difficile la comprensione e il miglioramento in futuro.

A pensarlo in un altro modo pensi che la normalizzazione sia una buona cosa? La normalizzazione di solito porta a un numero maggiore di tabelle, ma porta anche a soluzioni più gestibili, riduzione della duplicazione dei dati e gestione dei dati più semplice.

Naturalmente può anche portare a prestazioni più lente (supponendo che il database denormalizzato sia stato ben progettato).

In definitiva, devi pensare a quali sono i tuoi requisiti in queste aree, ma come posizione di partenza predefinita direi un livello ragionevole di normalizzazione e quindi verificare se ciò sta causando problemi specifici in cui un minor numero di tabelle potrebbe essere una soluzione.

Il numero non è importante. Il design è. Guarda alcuni sistemi là fuori. Magento, PHPBB, ecc. Hanno decine di tabelle nei loro sistemi e funzionano perfettamente.

Insieme alle preoccupazioni per la normalizzazione e le prestazioni, è possibile utilizzare "che richiederà un'altra tabella" come modo per gestire l'ambito di un'applicazione. Questa funzione richiederà una nuova tabella e tutto il tempo, l'energia e gli sforzi per progettare, costruire, testare, gestire gli aggiornamenti e tutte le altre codifiche coinvolte. L'aggiunta di 5 campi a tabelle esistenti (ove appropriato) è molto più semplice di una tabella a 5 colonne.

Se si progetta un database con il tentativo di ridurre al minimo la creazione di tabelle, si vedrà presto l'improvvisa difficoltà ed errori nei propri modi.

Il conteggio delle tabelle non dovrebbe essere in primo piano durante la creazione di un progetto di database. Metti le cose dove devono andare logicamente e relazionalmente.

Penso che il numero di tabelle sia importante e possa avere un grande impatto sulle prestazioni se si sceglie di dividere i dati che dovrebbero, a tutti gli effetti, rimanere uniti, in più tabelle (vale a dire quindi si dovrebbe avere un database normalizzato). Di solito quando lo fai, sarai costretto a JOIN Operations (o equivalente non SQL) per ottenere tutti i dati di cui hai bisogno e per tabelle abbastanza grandi strutturate in questo modo, le prestazioni si riducono rapidamente.

Non entrerò nei dettagli, ma penso che il fatto molto reale che il numero di tabelle possa influenzare le prestazioni sia uno dei motivi per cui sono stati inventati database noSQL come Cassandra, Mongo e Google BigTable (sic!), ed è anche per questo che incoraggiano la de-normalizzazione dei dati (e di conseguenza evitando un gran numero di tabelle / raccolte, ecc.).

Lo stesso si può dire per i server di ricerca come Solr di Apache che non incoraggiano o facilitano facilmente la suddivisione dei documenti in più "tabelle" o "tipi di voci", incoraggiandoti invece ad avere uno schema "uno che comprende tutti" che ha campi comuni a tutti i tipi di documenti che si desidera indicizzare (e di conseguenza evitare di dover eseguire operazioni simili a JOIN).

Non sto dicendo che il semplice fatto di avere x table in uno schema lo renderà necessariamente più lento di uno schema con x / 2 table tutte le volte, ma ci sono alcuni contesti in cui può portare a rallentamenti dovuti a conseguenti operazioni extra necessarie per aggregare i dati in tutte quelle tabelle. Continuando su questo, non penso che sia giusto dire "qualsiasi numero di tabelle e l'estrema normalizzazione dei dati non ha alcun impatto sulle prestazioni".

Lo zio Bob sosterrebbe che More è più semplice.

Vedi http://c2.com/cgi/wiki?FearOfAddingTables

"un buon design è generalmente semplificato aggiungendo tabelle"

Credo che quasi tutte le entità siano molte-a-molte, il che richiede più tabelle.

Crea una tabella dei paesi con al suo interno il codice del continente. Oh, non puoi perché in realtà ci sono 8 paesi transcontinentali. Lo stesso vale per le valute. Panama ne usa due.

Quindi la risposta è SÌ.

Ma dipende qual è il vero significato del numero "minimo" di tabelle.

Ad esempio (un anti-esempio).

Se avrò i prossimi oggetti

1. utenti
2. i clienti

ed entrambi condividono gli stessi stati (campi) e non ci sono restrizioni di sicurezza, quindi è più adatto a fare un'unica tabella

1. table_persons

piuttosto due tavoli diversi

1. table_users
2. table_customers

il contro è che nei table_persons dovremo aggiungere un nuovo campo (type_of_person).

Un altro errore (errore se non è proprio necessario) è quello di "dividere" una tabella, leggi come: separare una singola tabella in due.

1. table_persons

in due tavoli

1. table_info_persons
2. table_extra_info_persons

perché stai forzando alcune query a unire due tabelle ed è male.