Ist es notwendig, eine Datenbank mit möglichst wenigen Tabellen anzulegen?

52

Sollten wir eine Datenbankstruktur mit einer Mindestanzahl von Tabellen erstellen?

Sollte es so gestaltet sein, dass alles an einem Ort bleibt, oder ist es in Ordnung, mehr Tische zu haben?

Wird es irgendetwas beeinflussen?

Ich stelle diese Frage, weil ein Freund von mir eine Datenbankstruktur in mediaWiki geändert hat. Am Ende benutzte er statt 20 Tischen nur 8, und es dauerte 8 Monate, bis er das tat (es war sein College-Auftrag).

BEARBEITEN

Ich schließe die Antwort wie folgt: Größe der Tabellen spielt keine Rolle, bis der Fall außergewöhnlich ist; In diesem Fall kann die Denormalisierung helfen.

Vielen Dank an alle für die Antworten.

Shaheer
quelle
15
Die minimale Anzahl von Tabellen ist einfach. Serialisieren Sie einfach das Ganze zu master_table (table_name, col_name, col_type, row_id, value).
Inca
Was? Ich
verstehe
12
Da jedes Feld in einer Datenbank durch die Kombination von Tabellenname, Spaltenname, Primärschlüssel und Wert definiert wird, können Sie die Anzahl der Tabellen jederzeit reduzieren, indem Sie eine einzelne Tabelle denormalisieren, in der genau das gespeichert ist. Nicht sehr nützlich, aber durchaus möglich.
Inca
Nun, ich habe um des Wissens willen gefragt, und wenn etwas weniger nützlich ist als das existierende, warum sollte ich es dann ändern? Ich meine, wird es irgendetwas verbessern? Leistung zum Beispiel?
Shaheer
1
@Hamza: Möglicherweise wird die Leistung verbessert. Es hängt wirklich von den spezifischen Umständen ab. Es gibt hier nicht annähernd genug Informationen, um eine konkrete Antwort zu geben.
FrustratedWithFormsDesigner

Antworten:

155

Ignorieren Sie die Anzahl der Tabellen. Sorgen Sie sich mehr um das richtige Design . Wenn Ihr Hauptanliegen die Anzahl der Tabellen ist, sollten Sie wahrscheinlich keine Datenbanksysteme entwerfen.

Wenn Ihr Freund nur 8 Tische benötigte und das System damit einwandfrei funktioniert, ist 8 die richtige Zahl, und die restlichen 12 wären möglicherweise für das, was er tat, nicht erforderlich gewesen.

Mögliche Ausnahmen sind besondere Umgebungen, in denen die Anzahl der Tische stark eingeschränkt ist, aber ich kann mir kein konkretes Beispiel für ein solches System vorstellen.

FrustratedWithFormsDesigner
quelle
107
+1:If your major concern is quantity of tables, you should probably not be designing database systems.
Joel Etherton
9
Fazit: Eine Datenbanktabelle benötigt nicht viel zusätzlichen Platz. Es sind die Daten, die Platz beanspruchen. Normalisierung = mehr Tabellen = weniger Wiederholungen = weniger Speicherplatz. Indem Sie versuchen, die Anzahl der Tabellen zu minimieren, beeinträchtigen Sie nicht nur das Design, sondern verschwenden auch Platz . Dieses "Tischgolf" ist einfach rundum schlecht, es sei denn, einige der Tische sind buchstäblich überflüssig.
Aaronaught
1
+1, obwohl ich glaube, dass wir nicht genug wissen, um zu sagen, dass die richtige Zahl in seinem Fall 8 ist, da wir die Schemata nicht vergleichen können (das Original könnte besser mit einem höheren Transaktionsvolumen als die Anwendung derzeit z Beispiel)
Adam Robinson
2
@Hamza: Okay, er hat vielleicht gute PHP-Kenntnisse und gute Datenbankkenntnisse, und für dieses Projekt sind möglicherweise beide erforderlich - aber nehmen Sie nicht an, dass eines automatisch das andere impliziert. Viele Entwickler können eine Fähigkeit haben, aber nicht die andere.
FrustratedWithFormsDesigner
4
@Tom Anderson - Dann sollten Sie immer noch keine Datenbanksysteme entwerfen.
Joel Etherton
71

Eine Datenbank sollte genau so viele Tabellen enthalten, wie sie benötigt. Nicht weniger, nicht mehr.

Adam Crossland
quelle
3
Deutsch:. Englisch: emagazine.credit-suisse.com/app/art...1007 & lang = en Um dies nicht in eine Diskussion zu verwandeln, hier eine interessante Diskussion über die Debatte "weniger" gegen "weniger", einschließlich ihrer Ursprünge, aus der englischsprachigen SE , da es euch zu begeistern scheint;)
Corey
17

Datenbanktabellen sollten genau wie Klassen dem Prinzip der Einzelverantwortung entsprechen. Jede Tabelle sollte sich zunächst nur mit einer Gruppe zusammengehöriger Daten befassen. Abgesehen von der Leistung ist das ganze Biest dadurch einfacher zu verwalten, da die Tische selbst kleiner werden. Dadurch erhalten Sie auch eine bessere Leistung, da kleinere Tabellen schneller durchsucht und verknüpft werden können.

Kümmern Sie sich nicht mehr um die Anzahl der Tabellen als um die Anzahl der Klassen - machen Sie sich überhaupt keine Sorgen. Konzentrieren Sie sich darauf, guten, sauberen und lesbaren Code zu erstellen, und nicht darauf, wie viel Platz er einnimmt. Refactor aggressiv, sobald Sie ein funktionierendes Produkt haben, um es zu verbessern - und damit meine ich auch die Datenbank! Sie sehen Spalten, die sich in anderen Tabellen befinden sollten oder nicht benötigt werden usw. Sie können ein Profil erstellen, um zu sehen, welche Abfragen am längsten dauern und warum, und um diese Probleme zu beheben, wenn sie wirklich ein Problem sind.

Michael K
quelle
4
In einem normalisierten Datenmodell ist dies der beste Ansatz. Wenn die Datenbank jedoch für die Berichterstellung oder den primären Lesezugriff vorgesehen ist, sind denormalisierte "abgeflachte" Tabellen für große Datenmengen besser geeignet. Eine geringere Anzahl von Tabellen führt in diesem Fall zu weniger Verknüpfungen und einer besseren Leistung.
maple_shaft
2
@ Maple Stimme absolut zu. Sie müssen ein Profil erstellen, um zu bestimmen, welche Datensätze zu gruppieren sind. Daher müssen Sie IMO mit der Normalisierung beginnen. YMMV, Experten können es wahrscheinlich aus dem Häuschen machen :) Jeff hat einen Beitrag über Denormalisierung, den Sie vielleicht auch interessant finden.
Michael K
1
Guter und gelungener Beitrag, ich habe diesen schon einmal gelesen! Manchmal können Sie das Beste aus beiden Welten nutzen. Wenn die Berichterstellung nicht zu 100% in Echtzeit erfolgen muss, müssen zwei Schemas verwaltet werden. Das eine Hauptschema ist das für die Anwendung normalisierte Transaktionsschema und das andere ein denormalisiertes Schema, das regelmäßig gestreamt und für den Datenzugriffsbericht zugeschnitten wird.
maple_shaft
1
Weitere Informationen zum Thema mit einer Erklärung zu Star Schema: publib.boulder.ibm.com/infocenter/rbhelp/v6r3/…
maple_shaft
1
@maple_shaft, ich bin damit einverstanden, dass Berichtsdatenbanken aus Gründen der Leistung häufig denomalisiert werden, aber ich würde nicht erwarten, dass ein Student oder ein Junior-Programmierer sie übernehmen darf. Ich weiß, dass ich es auf keinen Fall zulassen würde, dass meine Data Warehouses von jemandem verwaltet werden, der keine nachgewiesenen Fachkenntnisse besitzt.
HLGEM
7

Eine Produktionsdatenbank für eine Geschäftsanwendung kann Hunderte oder sogar Tausende von Tabellen enthalten. Sie benötigen die Anzahl der Tabellen, die Sie für die Geschäftsanforderungen benötigen. Der Versuch, die Anzahl der Tabellen zu reduzieren, nur um weniger Tabellen zu haben, führt normalerweise zu einer Datenbank, die schwerer abzufragen ist, Datenintegritätsprobleme aufweist und viel schwerer zu warten ist als eine normalisierte Datenbank.

Es gibt Zeiten, in denen eine Denormalisierung erforderlich ist. Dies sollte nur von jemandem gemacht werden, der genau weiß, was er / sie tut und warum. Es ist sehr einfach, Denomalisierung durcheinander zu bringen, daher sollte dies nur von einem Datenbankspezialisten oder leitenden Anwendungsentwickler mit langjähriger Datenbankerfahrung durchgeführt werden. Eine unerfahrene Person sollte sich bemühen, mindestens die dritte Normalform zu erreichen (es sei denn, Sie führen Data Warehousing durch, ein Bereich, für den ich keine unerfahrene Person einstellen würde).

Wenn Leute sagen, dass Tabellen verkleinert werden, weil Verknüpfungen teuer sind, sind sie im Allgemeinen unwissend oder haben schlecht gestaltete Datenbanken, in denen wichtige Indizes fehlen, oder verwenden große natürliche Schlüssel mit mehreren Spalten. Relationale Datenbanken sind für die Verwendung von Verknüpfungen ausgelegt. Verknüpfungen können sehr effizient sein, wenn die FKs ordnungsgemäß indiziert sind und kleine Felder zum Verknüpfen verwenden (Ganzzahlen sind am effizientesten). Sie werden feststellen, dass große Unternehmen mit Terrabyte-großen Datenbanken auf irgendeine Weise eine hervorragende Leistung erzielen und Verknüpfungen verwenden.

Kein seriöser Datenbankdesigner versucht jemals, die Anzahl der Tabellen zu reduzieren, nur weil er weniger Tabellen haben möchte. Sie reduzieren die Anzahl der Tabellen, da die Daten nicht mehr benötigt werden oder Sie ein Leistungsproblem haben, das Sie auf keine andere Weise lösen können (und es gibt viele Möglichkeiten, es zu versuchen, bevor Sie das umfassende Risiko für Ihre Daten in Kauf nehmen, eine Tabelle zu denormalisieren). .

HLGEM
quelle
Google hat BigTable entworfen und die Verknüpfungen absichtlich ausgeschlossen, da sie nicht parallelisierbar sind.
Lie Ryan
2
@Lie Ryan, BigTable ist ein Sonderfall, der für die meisten Geschäftsanwendungen NICHT geeignet ist, da die Datenintegrität kein großes Problem darstellt. Google benötigt nicht sehr viele komplexe Geschäftsregeln für die Suche. Ich wette, ihre Finanzanwendung für Unternehmen verwendet BigTable nicht. Nichtsdestotrotz können die meisten Geschäftsanwendungen mit großen Datenbanken Verknüpfungen verwenden und eine gute Leistung erbringen, wenn der Designer über fundierte Kenntnisse verfügt. Unternehmensdatenbanken bieten zahlreiche Möglichkeiten zur Leistungsverbesserung (einschließlich Partitionierung) und müssen daher nicht die Datenintegritätsfunktionen einer relationalen Datenbank verlieren.
HLGEM
+1 für Sie, @HLGEM, sowohl für die Antwort als auch für den Kommentar; Es ist eine große Schande, dass viele Entwickler in die Dokumentendatenbank einsteigen, weil sie denken, dass "Joins = Slow" ist, nur um zu versuchen, relationale Probleme zu lösen, die vor 20 Jahren durch relationale Datenbanken gelöst wurden.
Adam Robinson
5

Da jedes Feld in einer Datenbank durch die Kombination von Tabellenname, Spaltenname, Primärschlüssel und Wert definiert wird, können Sie die Anzahl der Tabellen jederzeit reduzieren, indem Sie eine einzelne Tabelle denormalisieren, in der genau diese Tabelle gespeichert ist. Nicht sehr nützlich, aber durchaus möglich.

Tabellen sind eine abstrakte Ebene, die beim Umgang mit Daten hilfreich ist. Deshalb werden sie geschaffen. Ich habe es zu einem Witz gemacht, aber das Verständnis, dass Sie jeden Datensatz auf eine Haupttabelle reduzieren können, zeigt sofort, warum Sie das nicht sollten: weil Tabellen Ihnen etwas bringen. Auf konzeptioneller Ebene erhalten Sie eine Struktur, die für den Menschen einfacher zu verstehen ist als serialisierte Daten. Auf der dazwischen liegenden Ebene bringen sie das Konzept der Normalisierung mit sich: Vermeiden Sie das Speichern redundanter Daten und geben Sie einen einzigen Punkt für Änderungen an, anstatt etwas an mehreren Stellen zu ändern. Auf technischer Ebene bringen Datenbanken die meisten Dinge, die Sie mit Daten tun möchten, und zahlreiche Tools mit und implementieren und testen sie mehr, als Sie wahrscheinlich selbst tun werden. Denken Sie an Datentypen, Standardwerte, Benutzerrechte, Indizes, Fremdschlüsseleinschränkungen usw. Es wurde getestet, von vielen genutzt, optimiert und getestet. (Nicht in Perfektion, aber trotzdem.)

Da es sich bei einer Datenbank um ein Tool handelt, müssen Sie zunächst entscheiden, wie Sie das Tool verwenden möchten. Die Anzahl der Tische ist nicht wichtig. Eine Minimierung ist immer möglich, jedoch auf Kosten des Ausschlusses der Vorteile. (Wenn Sie mehr über Normalisierung lesen, werden Sie auf die wenigen Fälle für Denormalisierung stoßen - aber selbst dann geht es nur um die richtigen Entscheidungen und nicht nur darum , die Anzahl der Tabellen blind zu reduzieren.)

Inca
quelle
danke, es ist jetzt viel klar !, und ich habe über Normalisierung übrigens gelesen, ich mache es sogar in cakePHP-Datenbanken, was einen anderen und etwas anderen Ansatz fördert.
Shaheer
3

Sie sollten die richtige Anzahl von Tabellen verwenden. Sie könnten theoretisch mit einer einzigen Tabelle auskommen, indem Sie die gesamte Datenbank denormalisieren, aber die Datenbank wäre unbrauchbar. Dein Freund scheint zu viel Zeit zu haben.

Neil Butterworth
quelle
2

Die Mindestanzahl von Tischen zu haben, scheint mir ein sehr eigentümliches Ziel zu sein.

Das Reduzieren eines Schemas von 20 auf 8 Tabellen kann eine gute Sache sein (wenn es gut gemacht wird, kann es Verknüpfungen reduzieren und die Leistung steigern, nicht verwendete Spalten entfernen usw.), aber es kann auch schwieriger sein, die Zukunft zu verstehen und zu verbessern.

Anders ausgedrückt: Denken Sie, Normalisierung ist eine gute Sache? Normalisierung führt in der Regel zu einer größeren Anzahl von Tabellen, führt jedoch auch zu wartbareren Lösungen, einer geringeren Datenverdoppelung und einer einfacheren Datenverwaltung.

Natürlich kann dies auch zu einer geringeren Leistung führen (vorausgesetzt, die denormalisierte Datenbank wurde gut entworfen).

Letztendlich müssen Sie sich überlegen, welche Anforderungen Sie in diesen Bereichen haben. Als Standardausgangsposition würde ich ein angemessenes Maß an Normalisierung anstreben und dann prüfen, ob dies bestimmte Probleme verursacht, bei denen möglicherweise weniger Tabellen eine Lösung darstellen.

Jon Hopkins
quelle
0

Nummer ist nicht wichtig. Design ist. Schauen Sie sich einige Systeme an. Magento, PHPBB usw. Sie haben Dutzende von Tabellen in ihren Systemen und funktionieren einwandfrei.

Ryan Street
quelle
0

Zusammen mit Bedenken hinsichtlich Normalisierung und Leistung können Sie "das erfordert eine andere Tabelle" verwenden, um den Bereich einer Anwendung zu verwalten. Diese Funktion erfordert eine neue Tabelle und viel Zeit, Energie und Aufwand für das Entwerfen, Erstellen, Testen, Verwalten der Upgrades und aller anderen beteiligten Codierungen. Das Hinzufügen von 5 Feldern zu vorhandenen Tabellen (sofern zutreffend) ist viel einfacher als eine 5-Spalten-Tabelle.

JeffO
quelle
0

Wenn Sie eine Datenbank mit dem Ziel entwerfen, die Tabellenerstellung zu minimieren, werden Sie bald die abrupten Schwierigkeiten und Fehler in Ihren Wegen bemerken.

Bei der Erstellung eines Datenbankentwurfs sollte die Tabellenzahl nicht im Vordergrund stehen. Stellen Sie Dinge da auf, wo sie logisch und relational benötigt werden.


quelle
0

Ich denke, die Anzahl der Tabellen ist von Bedeutung und kann einen großen Einfluss auf die Leistung haben, wenn Sie Daten aufteilen, die in geschäftlicher Hinsicht in mehreren Tabellen zusammengefasst bleiben sollen (dh wenn Sie eine normalisierte Datenbank haben). Wenn Sie dies tun, müssen Sie in der Regel JOIN Operations (oder eine nicht mit SQL vergleichbare Methode) ausführen, um alle benötigten Daten zu erhalten, und bei ausreichend großen Tabellen, die so aufgebaut sind, sinkt die Leistung schnell.

Ich werde nicht auf Details eingehen, aber ich denke, dass die Tatsache, dass die Anzahl der Tabellen die Leistung beeinflussen kann, einer der Gründe ist, warum noSQL-Datenbanken wie Cassandra, Mongo und Google BigTable (sic!) Erfunden wurden. und das ist auch der Grund, warum sie zur De-Normalisierung von Daten ermutigen (und folglich eine große Anzahl von Tabellen / Sammlungen usw. vermeiden).

Dasselbe gilt für Suchserver wie Apaches Solr, die das Aufteilen Ihrer Dokumente in mehrere "Tabellen" oder "Arten von Einträgen" nicht wirklich fördern oder erleichtern und Sie stattdessen dazu ermutigen, ein "Ein umfasst alle" -Schema mit gemeinsamen Feldern zu verwenden auf alle Dokumenttypen, die Sie indizieren möchten (und daher keine JOIN-ähnlichen Vorgänge ausführen müssen).

Ich sage nicht, dass die einfache Tatsache, dass x-Tabellen in einem Schema enthalten sind, es notwendigerweise immer langsamer macht als ein Schema mit x / 2-Tabellen, aber es gibt bestimmte Kontexte, in denen es aufgrund von Konsequenzen zu Verlangsamungen kommen kann Zusätzliche Operationen, die zum Aggregieren der Daten in all diesen Tabellen erforderlich sind. Ich denke auch nicht, dass es in Ordnung ist zu sagen, dass "eine beliebige Anzahl von Tabellen und eine extreme Normalisierung der Daten keinen Einfluss auf die Leistung haben".

Shivan Drache
quelle
0

Onkel Bob würde argumentieren, dass More einfacher ist.

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

"Ein gutes Design wird im Allgemeinen durch Hinzufügen von Tabellen vereinfacht."

Ich glaube, dass fast alle Entitäten viele-zu-viele-Entitäten sind, was mehr Tabellen erfordert.

Erstellen Sie eine Ländertabelle mit dem darin enthaltenen Kontinentcode. Oh, das kannst du nicht, weil es tatsächlich 8 transkontinentale Länder gibt. Gleiches gilt für Währungen. Panama verwendet zwei.

Neil McGuigan
quelle
-2

Dann antworten Sie mit JA.

Aber hängen Sie davon ab, was die wahre Bedeutung der "minimalen" Anzahl von Tabellen ist.

Zum Beispiel (ein Anti-Beispiel).

Wenn ich die nächsten Objekte habe

  1. Benutzer
  2. Kunden

und beide haben die gleichen Zustände (Felder) und es gibt dann keine Sicherheitsbeschränkung, es ist besser, eine einzelne Tabelle zu erstellen

  1. table_persons

eher zwei verschiedene tische

  1. table_users
  2. table_customers

Die Nachteile sind, dass wir in den table_persons ein neues Feld hinzufügen müssen (type_of_person).

Ein anderer Fehler (Fehler, wenn es nicht wirklich nötig ist) ist, eine Tabelle zu "teilen", wie folgt: Trenne eine einzelne Tabelle in zwei.

  1. table_persons

in zwei Tabellen

  1. table_info_persons
  2. table_extra_info_persons

weil Sie zu einigen Abfragen gezwungen sind, zwei Tabellen zu verbinden, und es ist schlecht.

Magallane
quelle
Hey, deine Antwort ist sehr
anschaulich
2
Dies gibt mir einen Rückblick auf meine erste Unternehmensanwendung und die Datenbank dahinter und wie sehr der DBA es zum Albtraum gemacht hat, ein Tabellennazi für solche Dinge zu sein. Ich würde Kunden und Benutzer auf keinen Fall zusammenhalten, da es sich um völlig unterschiedliche Geschäftseinheiten handelt.
-1: Benutzer und Kunden haben unterschiedliche Felder; Wenn nicht zu diesem Zeitpunkt, werden sie irgendwann in der Zukunft haben. Sie verdienen also getrennte Tische.
Sjoerd
1
@Sjoerd, @Chris: Das mag zwar oft der Fall sein, muss aber nicht unbedingt stimmen. Solche Dinge sind anwendungsabhängig. Davon abgesehen stimme ich dem Gefühl zu. Zu oft sehen Datenbankentwickler, dass "allgemeine Feldnamen" bedeuten, dass es sich um dieselben Daten handelt. Dies ist besonders einfach, wenn Sie sich die Datenbank zuerst vom ORM aus (also rückwärts) ansehen. Während OO - Konzepte können in der Datenbank modelliert werden, Datenbanken sind Zeilen und Beziehungen, keine Objekte .
Adam Robinson
1
+1 für "Datenbanken sind Zeilen und Relationen, keine Objekte", füge ich meinen Favoriten hinzu!
Shaheer