it-swarm-eu.dev

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

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 dafür brauchte er 8 Monate (es war seine College-Aufgabe).

EDIT

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

Vielen Dank an alle für die Antworten.

52
Shaheer

IGNORIERE die Anzahl der Tabellen. Sorgen Sie sich mehr darum, das Design richtig zu machen. Wenn Ihr Hauptanliegen die Anzahl der Tabellen ist, sollten Sie wahrscheinlich keine Datenbanksysteme entwerfen.

Wenn Ihr Freund nur 8 Tische benötigt hat und das System damit einwandfrei funktioniert, ist 8 die richtige Nummer, und die restlichen 12 waren möglicherweise für das, was er tat, nicht erforderlich.

Mögliche Ausnahmen könnten besondere Umgebungen sein, in denen die Tischnummern stark eingeschränkt sind, aber ich kann mir kein konkretes Beispiel für ein solches System vorstellen.

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

71
Adam Crossland

Datenbanktabellen sollten genau wie Klassen dem Prinzip der Einzelverantwortung entsprechen. Jede Tabelle sollte zunächst nicht mehr als eine Gruppe zusammengehöriger Daten enthalten. Abgesehen von der Leistung erleichtert dies die Verwaltung des gesamten Tieres, da die Tabellen selbst kleiner sind. Dies bietet Ihnen auch eine bessere Leistung, da kleinere Tabellen schneller gesucht und verknüpft werden können.

Sorgen 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 Speicherplatz er hat nimmt auf. Refactor aggressiv, sobald Sie ein funktionierendes Produkt haben, um es besser zu machen - und ich meine auch die Datenbank! Sie sehen Spalten, die sich in anderen Tabellen befinden sollten oder nicht benötigt werden usw. Profil, um zu sehen, welche Abfragen am längsten dauern und warum, und diese Probleme zu beheben, wenn sie wirklich ein Problem sind.

17
Michael K

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 schwieriger abzufragen ist, Datenintegritätsprobleme aufweist und viel schwieriger zu warten ist als eine normalisierte Datenbank.

Es gibt Zeiten, in denen eine Denormalisierung erforderlich ist. Dies sollte nur von jemandem durchgeführt werden, der genau weiß, was er/sie tut und warum. Es ist sehr einfach, die Denomalisierung zu vermasseln, daher sollte dies nur von einem Datenbankspezialisten oder erfahrenen Anwendungsentwickler mit langjähriger Datenbankerfahrung durchgeführt werden. Eine unerfahrene Person sollte sich bemühen, in jeder von ihr entworfenen Datenbank mindestens die dritte normale Form zu erreichen (es sei denn, Sie führen Data Warehousing durch, für das ich keine unerfahrene Person einstellen möchte).

Wenn Leute sagen, dass sie die Tabellen reduzieren, weil Verknüpfungen teuer sind, sind sie im Allgemeinen unwissend oder haben schlecht gestaltete Datenbanken, in denen kritische Indizes fehlen oder die große natürliche Schlüssel mit mehreren Spalten verwenden. Relationale Datenbanken sind für die Verwendung von Verknüpfungen ausgelegt, und 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 es großen Unternehmen mit Terrabyte-Datenbanken irgendwie gelingt, eine hervorragende Leistung zu erzielen und Joins zu verwenden.

Kein seriöser Datenbankdesigner versucht jemals, die Anzahl der Tabellen zu reduzieren, nur weil er weniger Tabellen möchte. Sie reduzieren die Anzahl der Tabellen, weil die Daten nicht mehr benötigt werden oder Sie ein Leistungsproblem haben, das Sie nicht auf andere Weise lösen können (und es gibt viele Möglichkeiten, dies zu versuchen, bevor Sie das mfangreiches Risiko to übernehmen Ihre Daten zur Denormalisierung einer Tabelle).

7
HLGEM

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 sie in eine einzelne Tabelle denormalisieren, in der genau das gespeichert ist. Nicht sehr nützlich, aber durchaus möglich.

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

Da eine Datenbank ein Werkzeug ist, ist die Hauptsache die Entscheidung, wie das Werkzeug verwendet wird. Die Anzahl der Tabellen ist nicht wichtig. Minimieren ist immer möglich, jedoch auf Kosten des Wegwerfens der Vorteile. (Wenn Sie mehr über Normalisierung lesen, werden Sie auf die wenigen Fälle der Denormalisierung stoßen - aber selbst dann geht es nur um die rechts Entscheidungen, anstatt nur blind die Anzahl der Tabellen zu reduzieren.)

5
Inca

Sie sollten die Anzahl rechts der Tabellen verwenden. Sie könnten theoretisch mit einer einzelnen Tabellentabelle auskommen, indem Sie die gesamte Datenbank denormalisieren, aber die Datenbank wäre unbrauchbar. Dein Freund scheint zu viel Zeit zu haben.

3

Die Mindestanzahl an Tischen zu haben, scheint mir ein sehr eigenartiges 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 könnte es auch schwieriger machen, die Zukunft zu verstehen und zu verbessern.

Wenn Sie es anders sehen, denken Sie, dass Normalisierung eine gute Sache ist? Die Normalisierung führt normalerweise zu einer größeren Anzahl von Tabellen, aber auch zu wartbareren Lösungen, einer geringeren Datenverdoppelung und einer einfacheren Datenverwaltung.

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

Letztendlich müssen Sie über Ihre Anforderungen in diesen Bereichen nachdenken, aber als Standardstartposition würde ich sagen, dass Sie ein angemessenes Maß an Normalisierung anstreben und dann prüfen, ob dies bestimmte Probleme verursacht, bei denen weniger Tabellen eine Lösung sein könnten.

2
Jon Hopkins

Ich denke, die Anzahl der Tabellen ist wichtig und kann einen großen Einfluss auf die Leistung haben, wenn Sie Daten, die für alle geschäftlichen Absichten und Zwecke zusammen bleiben sollen, in mehrere Tabellen aufteilen (d. H. Damit Sie eine normalisierte Datenbank haben). Wenn Sie dies tun, müssen Sie normalerweise JOIN Operations (oder ein Nicht-SQL-Äquivalent) ausführen, um alle benötigten Daten abzurufen. Bei ausreichend großen Tabellen, die so strukturiert sind, sinkt die Leistung schnell.

Ich werde nicht auf Details eingehen, aber ich denke, dass die sehr reale 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 deshalb fördern sie auch die De-Normalisierung von Daten (und vermeiden folglich eine große Anzahl von Tabellen/Sammlungen usw.).

Gleiches 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 auf einfache Weise erleichtern und Sie stattdessen dazu ermutigen, ein "Eins umfasst alle" -Schema mit gemeinsamen Feldern zu verwenden auf alle Dokumenttypen, die Sie indizieren möchten (und folglich vermeiden, JOIN-ähnliche Operationen ausführen zu müssen).

Ich sage nicht, dass die einfache Tatsache, x Tabellen in einem Schema zu haben, 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 erforderlich sind, um die Daten in all diesen Tabellen zu aggregieren. Wenn ich damit fortfahre, denke ich auch nicht, dass es in Ordnung ist zu sagen, "eine beliebige Anzahl von Tabellen und eine extreme Normalisierung der Daten haben keinerlei Auswirkungen auf die Leistung".

0
Shivan Dragon

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

0
JeffO

Wenn Sie eine Datenbank entwerfen, in der versucht wird, die Tabellenerstellung zu minimieren, werden Sie bald die abrupte Schwierigkeit bemerken und sich auf Ihre Weise irren.

Die Anzahl der Tabellen sollte beim Erstellen eines Datenbankdesigns nicht im Vordergrund stehen. Platzieren Sie Dinge dort, wo sie logisch und relational sein müssen.

0
user29981

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 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.

0
Neil McGuigan

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

0
Ryan Street