Frage zu effizienter Datenbankstruktur

M

Magical

Angesehenes Mitglied
Hallo,

ich bin gerade dabei eine neue Datenbank aufzubauen, welche bereits aus vielen kleineren Tabellen besteht.
Allerdings gibt es noch eine recht große Tabelle, bei der ich überlege, welche Lösung hier besser ist.
Hautpsächlich werden im ersten Schritt nur einzelne Daten/Spalten abgefragt und auch für den INSERT sollen nur wenige Spalten zwingend erforderlich sein zur Identifizierung des Objekts.
Macht es in diesem Fall Sinn, diese Tabelle aufzuteilen (sozusagen in "Grunddaten" (aktuelle Planung ca. 11 Spalten) und "weitere Details" (aktuell geplant ca. 15 Spalten - Eingaben wären jeweils optional)) oder ist es besser diese in einer Tabelle zu belassen?
Einige der Spalten beinhalten bereits nur den Index einer Untertabelle (wie Farbangaben, Status, Eigenschaftenm Zugehörigkeiten - die Normalisierung versuche ich also bereits weitestgehend zu berücksichtigen). Ein paar wenige (Beschreibungen/Text) sollen aber mehrsprachig sein, so dass ich hierfür mehrere Spalten einplane.

Zusätzlich plane ich auch (schon der Übersichtlichkeit wegen) noch eine weitere Tabelle (index=index Haupttabelle), in welcher es eine lange Beschreibung mit Unterteilung in verschiedene Kategorien (einzelne Spalten, da nicht jedes Objekt zu jeder Kategorie Einträge haben wird) geben soll. Hierbei wird es jede Spalte zu Beginn zweimal (2 Sprachen) geben.

Da eine zu große Aufspaltung für die Performance sicher auch nicht gerade förderlich ist, bin ich jetzt am Überlegen, ob ich die Haupttabelle nochmals aufteilen sollte oder ob knapp 30 Spalten keine erwähnenswerte Verschlechterung der Performance bringen. oder eventuell sogar günstiger sind als eine Aufteilung...

Würde mich über Meinungen (oder auch hilfreiche Links) hierzu freuen...
 
Grundsätzlich bringt es eher einen Performancevorteil, wenn alle zusammengehörigen (Normalisierung) Daten in derselben Tabelle sind. Man muss ja nicht immer alle Spalten auslesen, sondern kann auch nur diejenigen Daten holen, die man aktuell grad braucht. Teilt man solche Tabellen in mehrere "kleinere" Tabellen auf, dann muss man wieder joinen, wenn alle Daten zusammen gebraucht werden. Und ein Join ist immer ein Performancenachteil.

Eine anständige Datenbank stört sich an leeren Spalten nicht, es wird weder Speicherplatz verschwendet noch entsteht ein Performancenachteil.

QUOTE (Magical @ Mi 22.08.2007, 13:19)Einige der Spalten beinhalten bereits nur den Index einer Untertabelle (wie Farbangaben, Status, Eigenschaftenm Zugehörigkeiten - die Normalisierung versuche ich also bereits weitestgehend zu berücksichtigen).


Dann lass diese Spalten einfach leer resp. setz sie auf Null, wenn sie (noch) keine Zugehörigkeit haben.


QUOTE (Magical @ Mi 22.08.2007, 13:19)Ein paar wenige (Beschreibungen/Text) sollen aber mehrsprachig sein, so dass ich hierfür mehrere Spalten einplane.

Zusätzlich plane ich auch (schon der Übersichtlichkeit wegen) noch eine weitere Tabelle (index=index Haupttabelle), in welcher es eine lange Beschreibung mit Unterteilung in verschiedene Kategorien (einzelne Spalten, da nicht jedes Objekt zu jeder Kategorie Einträge haben wird) geben soll. Hierbei wird es jede Spalte zu Beginn zweimal (2 Sprachen) geben.


Ich würde Dir dringend empfehlen, auch die Mehrsprachigkeit voll zu normalisieren. Also nicht pro Sprache eine Spalte, sondern ein Record in einer Sprachtabelle. Das Ganze wird sich sicher noch weiterentwickeln, und Du schreibst ja "zu Beginn zweimal", was heisst es könnten ja auch noch mehr Sprachen werden. Mit dem Spalten-Ansatz ist es dann sehr unübersichtlich.

Griessli
Irene
 
Vielen Dank für die Antwort - dann werde ich es wohl doch lieber bei der einen Haupttabelle belassen.

QUOTE Ich würde Dir dringend empfehlen, auch die Mehrsprachigkeit voll zu normalisieren. Also nicht pro Sprache eine Spalte, sondern ein Record in einer Sprachtabelle. Das Ganze wird sich sicher noch weiterentwickeln, und Du schreibst ja "zu Beginn zweimal", was heisst es könnten ja auch noch mehr Sprachen werden. Mit dem Spalten-Ansatz ist es dann sehr unübersichtlich.


Meinst Du hier einzelne Tabellen für die jeweiligen Sprachen? (für jedes Objekt und jede Untertabelle jeweils eine Untertabelle in der entsprechenden Sprache?) Das hatte ich zu Beginn auch mal angedacht...und ein wenig gegoogelt...wobei ich für Sprachauswahl mehr bei Spalten gelandet war.
Bei einer solchen Unterteilung wäre es ja dann auch sinnvoller, die lange Beschreibung direkt mit in die Haupttabelle zu übernehmen, damit alle Daten zusammensind...

Würde es dann aber nicht wieder zu doppelten Datensätzen oder zumindest Dopplung bei einigen Werten kommen? Als ein Beispiel für eine Untertabelle die Geodaten zu verschiedenen Orten weltweit. In diesem Fall würde sich ja jeweils nur in einigen Fällen der Name des Ortes ändern, die Längen-&Breitengrade sowie die PLZ/ZIP bleiben unverändert.
Wäre das dann nicht wieder negativ für Speicherplatz und Performance?
Wenn Speicherplatzintensiver aber besser für die Performance wäre es auf jeden Fall auch interessant...und ich lasse meine Vermutung auch bezüglich der negativen Auswirkung auf die Performance gern berichtigen, falls sie falsch sind..
 
Was du berücksichtigen solltest:

- Je mehr Indizes in einer Tabelle sind, desto länger dauert ein Schreibbefehl wie INSERT oder UPDATE
- SELECT * FROM... ist schneller als SELECT spalte FROM... das hebt sich aber auf, wenn eine Tabelle sehr viele Spalten hat.
- Alle Daten die nur zur Detailbetrachtung da sind, sollten in einer andere Tabelle sein (sie werden ja nur einzeln aufgerufen und werden nicht zum Auflisten benötigt)

Was Irene meinte, sind Datensätze, nicht Untertabellen.
zB.
Datensatz1 Deutsch: 1 | 1 | xyz | abc | de
Datensatz1 Englisch: 2 | 1 | xyz | abc | en
Datensatz2 Deutsch: 3 | 2 | xyz | abc | de
Datensatz2 Englisch: 4 | 2 | xyz | abc | en

Erste Spalte ist der primäre Autoindex und Spalte 2 ist der Datensatz-Index, den man 1 mal pro Sprache hat.
 
QUOTE (Maik @ Mi 22.08.2007, 14:28)Was Irene meinte, sind Datensätze, nicht Untertabellen.
zB.
Datensatz1 Deutsch: 1 | 1 | xyz | abc | de
Datensatz1 Englisch: 2 | 1 | xyz | abc | en
Datensatz2 Deutsch: 3 | 2 | xyz | abc | de
Datensatz2 Englisch: 4 | 2 | xyz | abc | en

Genauso meinte ich das, vielen Dank
smile.gif



QUOTE Als ein Beispiel für eine Untertabelle die Geodaten zu verschiedenen Orten weltweit. In diesem Fall würde sich ja jeweils nur in einigen Fällen der Name des Ortes ändern, die Längen-&Breitengrade sowie die PLZ/ZIP bleiben unverändert.

In diesem Fall würden die Namen der Orte in die Sprachtabelle ausgelagert. Alle nicht-sprachspezifischen Daten wie PLZ und Koordinaten etc. bleiben in ihrer Tabelle.

Griessli
Irene
 
ok, ich glaub ich hab das jetzt verstanden..die Untertabellen (z.B. Farbe) bekommen jeweils zwei index-Felder (1x Autoindex und 1x Wert-index (in dem Beispiel z.B. fard_index)) und in der Haupttabelle gebe ich dann den Wert index (in dem Fall farb_index) an.
Das spart natürlich schon einiges an Spalten (bei ein paar Tabellen)..und ist auch später besser erweiterbar, falls weitere Sprachen dazukommen.
Das hilft mir sehr viel weiter - und da bin ich froh, dass ich vor Anlage der Datenbank nochmal hier nachgefragt habe :)
Danke für die guten Hinweise hierzu :)

@Maik
das mit der Anzahl der Index-Werte in der Haupttabelle lässt sich nur schlecht anders lösen...vieles wären ansonsten m:n-Beziehungen oder auch Wiederholungen in den unterschiedlichen Datensätzen (wie bei der Farbe). Ich glaub hier macht das dann schon Sinn nur mit den jeweiligen Index-Werten der Untertabellen zu arbeiten.
Für einige andere Zusammengehörigkeiten gibt es dann auch wieder kleinere Untertabellen, die nur den Zweck haben bestimmte andere Untertabellen miteinander zu verlinken, damit es keine m:n-Beziehungen gibt.
(ist insgesamt eine sehr komplexe Datenbankstruktur..)

Aber den Hinweis mit der Detailbetrachtung werde ich auf jeden Fall berücksichtigen und dann wohl doch die lange Beschreibung in einer Extra-Tabelle belassen, so dass ich hier auch gleich die Sprachauswahl mit hinterlegen kann.
 
die Tabelle die du zum Auflisten verwendest, zB. bei einem Shop die Tabelle die alle Produkte drin hat, sollte man statisch lassen (kein Varchar,Text oder Blob)... denn statische Tabellen sind wesentlich schneller zu scannen. In deinem Fall könnte es also sinn machen die Farbe und die Detailbeschreibung da rauszunehmen, und erst bei der Ausgabe durch eine 2. Query oder eine Subquery abzufragen. Kommt aber ganz darauf an, wieviele Einträge deine Haupttabelle bekommt.
 
@Maik

es sollen schon sehr viele (einige tausende) Objekte werden, wobei die Angaben zu Farben und Eigenschaften in der Haupttabelle eher statisch sind. Es gibt zwar ein paar wenige Felder, in denen sich die Daten unter Umständen ändern können, dies ist aber eher seltener der Fall.
Ich hab jetzt zwar noch 4 vchar-Felder in der Tabelle (die restlichen nur Zahlenwerte, da sie auf den Wert in einer anderen Tabelle verweisen), aber die sind vollständig statisch (wie der Name des Objekts).

Die Angaben zum Objekt, welche sich eher ändern oder wovon einem mehrere zugeordnet werden können, habe ich bereits ausgegliedert und entsprechende linked-tabellen angelegt (bei m:n-Beziehungen).

trotzdem danke für den Hinweis (versuche ihn auch bei den entsprechenden Untertabellen zu berücksichtigen, welche eine andere Ebene darstellen) :)
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben