Viele Datensätze vs Viele Tabellen

5 Antworten

Vom Beitragsersteller als hilfreich ausgezeichnet

Die Verteilung auf viele einzelne Tabellen bringt kaum Leistungszuwachs, weil die Daten nach deren Benutzer-ID indiziert werden können und über diesen Index die Eingrenzung des Zugriffs in einer großen, zusammenfassenden Tabelle auf diese Benutzer-ID nicht langsamer sein KANN als wenn die DB-Engine einen zweistufigen Zugriff ausklabüsern muß, wo sie ZUERST die Datenbanktabelle nach der Benutzer-ID aus der Menge der vorhandenen Datenbanktabellen suchen muß, bevor sie die eigentliche Abfrage ausführen kann.

Das Eingrenzen auf die Benutzer-ID innerhalb einer großen Tabelle sollte, wenn es denn überhaupt einen Unterschied geben sollte, schneller sein als das Eingrenzen auf die richtige Tabelle in der Tabellenmenge. Weil ersteres ein primäres Optimierungsziel von Datenbank-Engines ist, letzteres dagegen in der Praxis kaum gefragt (aber wahrscheinlich wird die Verwaltung der Tabellen innerhalb der DB-Engine nach exakt demselben Verfahren laufen wie jede andere Tabellenverwaltung - jedenfalls machen das mir bekannte DB-Engines so - und deshalb in der Regel keinen großen Unterschied ergeben).

Ich würde sagen: Mache es so, daß Du den geringsten Aufwand mit der Verwaltung (in Deiner programmierten Software) hast!


Jariz 
Beitragsersteller
 13.08.2013, 16:07

Vielen Dank ;) auch an alle anderen

Es ist verrückt wohlmöglich unendlich viele Tabellen oder gar Datenbanken zu erstellen.

Wenn es nur 20 Verschieden Arten von Daten sind dann nim jeweils dafür eine Tabelle und pack dort alle Datensätze aller user rein. Noch besser wäre es vllt wenn du die Daten gruppieren könntest, wenn nicht auch nicht schlimm.

Du kannst dann auch MySQL Joints ausführen und dir sofort alle Datensätze eines Nutzers zeigen lassen o.ä..

Gruß Christian

Die Frage, in wieviele Tabellen die Daten zu verteilen sind und welchen Aufbau diese haben müssen, ist keine Frage, die willkürlich festgelegt werden kann. Das muss sich aus dem Konzept ergeben, nach logischen Gesichtspunkten. So einfach was aus dem Handgelenk schütteln und passt schon, ist kaum eine richtige Datenbanklösung hinzubekommen.

Die Daten auf mehrere Datenbanken zu verteilen sollte man nur im Notfall, wenn es anders gar nicht geht. Das Verteilen auf Tabellen ist ein Kernstück der Datenbankkonzeption. Spätestens, wenn man die Datenbank auswerten muss, stellt sich heraus, ob man das richtig gemacht hat. Wenn Du genau weißt, welche Anforderungen die Datenbank erfüllen muss und wie Du das bewerkstelligen möchtest, dann weißt Du auch, wie Du die Daten auf die Tabellen verteilen musst.

Also ich würde das alles in eine große Tabelle packen. Kann das jetzt zwar performancetechnisch nicht genau begründen, aber jede Tabelle erzeugt einen gewissen Overhead der wesentlich größer sein dürfte als ein Feld mit Benutzerkennung


wotan38  10.08.2013, 10:04

Das dürfte so ziemlich das Verkehrteste sein, was man machen kann. Die Vorteile der relationalen Datenbank liegen darin, dass man komplexe Datenbankstrukturen realisieren kann, die dann auch viele Möglichkeiten für komplexe Abfragen bieten. Das wird durch die (gekonnte) Verteilung der Daten auf mehrere Tabellen erreicht. Alles in eine Tabelle packen, da kannst gleich einen Editor (oder Excel) nehmen und schauen, wie Du damit klar kommst.

Überleg dir vorher wie die Abfragen der Funktionalitäten aussehen sollen. Wenn es ein großes Projekt werden soll, kommst du um einen ausgiebigen Datenbankentwurf nicht herum. Generell musst du dir überlegen, welche Attribute oft zusammen benötigt werden. Um unnötige joins zu vermeiden, kommen entsprechende Attribute in eine Tabelle.

Für eine umfangreiche Normalisierung ist Grundlagenwissen gefragt. Ich habe das hier http://www.amazon.de/Grundlagen-von-Datenbanksystemen-Pearson-Studium/dp/3827370213/ref=sr_1_1?ie=UTF8&qid=1376082932&sr=8-1&keywords=Ramez+A.+Elmasri%2C+Shamkant+B.+Navathe