E 'necessario creare un database con il minor numero possibile di tabelle

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

Se il tuo amico ha bisogno solo di 8 tavoli e il sistema funziona correttamente, allora 8 è il numero corretto, e i restanti 12 potrebbero non essere stati necessari per quello che stava facendo.

Eventuali eccezioni potrebbero essere ambienti particolari che hanno forti limiti sui numeri di tabella, ma non riesco a pensare ad un esempio concreto di un sistema del genere in cima alla mia testa.

Un database dovrebbe avere esattamente quante tabelle ha bisogno. Non meno, non di più.

Le tabelle del database dovrebbero aderire al Principio di Responsabilità Unica, proprio come dovrebbero essere le classi. Ogni tabella dovrebbe occuparsi di non più di un gruppo di dati correlati per iniziare. Prestazioni a parte, questo rende l'intera bestia più facile da gestire, perché i tavoli stessi saranno più piccoli. Questo ti offre anche prestazioni migliori, perché le tabelle più piccole sono più veloci da cercare e partecipare.

Non preoccuparti del numero di tavoli più di quanto ti preoccupi del numero di classi - non ti preoccupare affatto concentrati a creare codice buono, pulito, leggibile, non su come molto spazio occupa. Refactor aggressivamente una volta che hai un prodotto funzionante per renderlo migliore - e intendo anche il database! Vedrai le colonne che dovrebbero trovarsi in altre tabelle, o non sono necessarie, ecc. Profilo per vedere quali query richiedono più tempo e perché, e risolvi questi 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 il fatto di avere meno tabelle di solito si traduce in un database più difficile da interrogare, presenta problemi di integrità dei dati ed è molto più difficile da gestire 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 facile smascherare lo smascheramento, 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, come minimo, di raggiungere la terza forma normale (a meno che non si stia facendo il data warehousing che è un'area che non considererei assumere una persona inesperta per) in qualsiasi database che lui / lei progetta.

Quando le persone dicono di ridurre le tabelle perché i join sono costosi, in genere sono ignoranti o hanno database mal progettati che mancano di indici critici o utilizzano chiavi naturali di mulit-column di grandi dimensioni. I database relazionali sono progettati per l'utilizzo di join e join che possono essere abbastanza efficienti se gli FK sono correttamente indicizzati e utilizzano campi piccoli per partecipare (gli interi sono più efficienti). Noterai che le grandi aziende che hanno database di terrabyte in qualche modo riescono a ottenere prestazioni eccellenti e utilizzano join.

Nessun progettista di database serio cerca mai di ridurre il numero di tabelle solo perché vogliono meno 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 assumere il rischio esteso 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 lo memorizza. Non molto utile, ma interamente possibile.

Le tabelle sono un livello astratto che aiuta a gestire i dati. Questo è il motivo per cui sono stati creati. L'ho fatto uno scherzo, ma capire che è possibile ridurre ogni set di dati a una tabella principale indica immediatamente perché non si dovrebbe: perché i tavoli ti portano qualcosa. A livello concettuale, ti offrono una struttura più facile da capire per gli umani rispetto ai dati serializzati. Al livello intermedio portano il concetto di normalizzazione: evitare di salvare dati ridondanti e dare un singolo punto per le modifiche, piuttosto che modificare qualcosa su più punti. A livello tecnico, i database portano la maggior parte delle cose che vuoi fare con i dati, numerosi strumenti e li implementano e li testano più di quanto probabilmente farai da soli. Pensa a tipi di dati, valori predefiniti, diritti degli utenti, indici, vincoli di chiavi esterne, ecc. È stato testato, utilizzato da molti, ottimizzato, debuggato. (Non nella perfezione, ma ancora.)

Poiché un database è uno strumento, la cosa principale è decidere come utilizzare lo strumento. Il numero di tavoli non è importante. Minimizzare è sempre possibile ma a costo di buttar via i benefici. (Se leggi di più sulla normalizzazione, ti imbatterai in alcuni casi di denormalizzazione, ma anche in questo caso si tratta esclusivamente delle decisioni giuste piuttosto che ridurre ciecamente il numero di tabelle.)

Dovresti usare il giusto numero di tabelle. Potresti teoricamente accontentarti di un tavolo unico 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 fino a 8 potrebbe essere una buona cosa (se fatto bene potrebbe ridurre i join e aumentare le prestazioni, rimuovere le colonne non utilizzate e così via) ma potrebbe anche rendere più difficile capire e migliorare in futuro .

Pensare 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, a una duplicazione dei dati ridotta ea una gestione dei dati più semplice.

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

In definitiva, devi pensare a quali sono le tue esigenze in queste aree, ma come posizione iniziale predefinita direi di raggiungere un ragionevole livello di normalizzazione e poi verificare se ciò sta causando problemi specifici in cui un numero inferiore 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 bene.

Oltre 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 funzionalità richiederà una nuova tabella e tutto il tempo, energie e sforzi per progettare, costruire, testare, gestire negli aggiornamenti e tutte le altre codifiche coinvolte. Aggiungere 5 campi alle tabelle esistenti (dove appropriato) è molto più semplice di una tabella di 5 colonne.

Se progetti un database cercando di ridurre al minimo la creazione della tabella, vedrai presto la brusca difficoltà e sbaglierai nei tuoi modi.

Il conteggio delle tabelle non dovrebbe essere in prima linea nella tua mente quando si crea una progettazione di database. Metti le cose dove devono logicamente e relazionalmente.

Penso che il numero di tavoli contenga e possa avere un impatto notevole sulle prestazioni se si sceglie di dividere i dati che dovrebbero, per tutti gli intenti e le finalità aziendali, stare insieme in più tabelle (ovvero 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, la performance si blocca velocemente.

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

Lo stesso potrebbe dirsi per i server di ricerca come Solr di Apache che non incoraggia o facilita facilmente la suddivisione dei tuoi documenti in più "tabelle" o "tipi di voci" incoraggiandoti invece ad avere uno schema "uno comprende tutti" che ha campi comuni a tutti i tipi di documento che vuoi indicizzare (e di conseguenza evitare di dover fare operazioni simili a JOIN).

Non sto dicendo che il semplice fatto di avere tabelle x in uno schema renderà necessariamente più lento di uno schema con tabelle x / 2 tutte le volte, ma ci sono determinati contesti in cui può portare a rallentamenti a causa delle conseguenti operazioni aggiuntive necessarie per aggregare i dati in tutte quelle tabelle. Continuando su questo, non penso che sia corretto affermare che "un numero qualsiasi di tabelle e un'estrema normalizzazione dei dati non hanno alcun impatto sulle prestazioni".

Lo zio Bob sosterrebbe che More is Simple.

Vedi link

"un buon design è generalmente semplificato aggiungendo le tabelle"

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

Crea una tabella di paesi con il codice del continente in essa contenuto. Oh, non puoi perché ci sono in realtà 8 paesi transcontinentali. Lo stesso con le valute. Panama ne usa due.

Quindi la risposta è SI.

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

Ad esempio (un anti-esempio).

Se ho gli oggetti successivi

1. utenti
2. i clienti

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

1. table_persons

piuttosto due diverse tabelle

1. table_users
2. table_customers

il contro è rispetto a table_persons avremo bisogno di aggiungere un nuovo campo (type_of_person).

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

1. table_persons

in due tabelle

1. table_info_persons
2. table_extra_info_persons

perché stai costringendo a alcune query per unirti a due tabelle ed è un problema.