Frage zum DB-Design

[Mario Rosenbohm]

Hallo,

wir haben folgendes Problem:

Wir wollen eine DB entwerfen, die Inhalte verschiedenster Kategorien speichert (Fachdaten für ein GIS-System).

Nun haben wir uns zu einem Entwurf entschlossen, der in etwa so aussieht:

[Stammdaten] (ID, Feld1, Feld2 ..)

[Detailtext] (ID, FK_Stammdaten_ID, FK_Texttype_ID, Text]

[Texttype] (ID, Bezeichnung, Vorgabe)

[Detailwert] (ID, FK_Stammdaten_ID, FK_Werttype_ID, Wert]

[Werttype] (ID, Bezeichnung, Vorgabe)

(ich hoffe es ist verständlich geschrieben ?!)

Damit können wir verschiedenste Parameter (Text und Zahl) zum Objekt (Stammdatensatz) speichern.

Nun kommen da ein paar Leute die sagen, das es mit sehr großen Datenmengen ( größer 1-2GB) bei Anfragen (Join über diese Tabellen um alle zum Datensatz gehörigen Parameter incl. Type auszulesen) zu "unverantwortlichen Abfragezeiten" kommt. Und wollen daher einfach die Stammtabelle um ... Felder erweitern.
Jedoch wird doch die DB dadurch nicht mehr skalierbar.
Für jeden Sachverhalt ein neues Feld (DB-Design nach EXCEL Manier).

Meine Meinung ist jedoch : Natürlich kommt es zu sehr hohen Abfragezeiten, wenn ich die Tabellen (gerade Detailtext und Detailwert) mit einem normalen Join verbinde. Da Oracle im Hintergrund eine Produkttabelle aus den Joins aufbauen muß.
Wenn diese Tabellen dann mehrere Mio-DS haben, dann .....

Aber wenn ich die Detailtabellen vorselektiere und diese "Selects" mit einem Join verbinde, dann sollten doch die Zeiten ertäglich bleiben. Oder?

Gibt es ähnliche Entwürfe (wie unsere) mit sehr vielen Datensätzen im Einsatz. Wie sind dort Erfahrungen mit Joins etc.?

Gruß Mario

[Falk Prüfer]

Hallo Mario,

ORACLE ist schließlich ein RDBMS, also sollte man die Relationalen (oder besser Objektrelationalen) Möglichkeiten auch nutzen und die Strukturen nicht künstlich "Plattklopfen" um sich einen vermeintlichen Performancevorteil zu verschaffen. Wenn ein paar Grundregeln beachtet werden (numerische Primärschlüssel, sinnvolle Indizes, etc.) und noch ein paar "Feinheiten" (z.B. regelmäßige Tabellenanalyse für den Optimizer) ausnutzt, dann ist ORACLE auch mit ein paar Mio-DS und mehrfach verschachtelten Joins rattenschnell. In der Regel sind nicht die PK/FK-Joins das Problem für "unverantwortliche Ladezeiten", sondern ungünstig gewählte Bedingungen der Hauptabfrage. Wenn aber das Ändern eines Stammdatenwertes über einen Trigger ein Update in 25 Tabellen mit jeweils 1 Mio. DS zur Folge hat (um die Konsistenz der "Exceltabellen" zu wahren), dann holst du dir mit Sicherheit ein Kaffevergiftung (die Rollbacksegmente sollten dann auch nicht unterdimensioniert sein) und die Ursache liegt eindeutig im falschen Design.
In bestimmten (zeitkritischen) Bereichen - z.B. für umfangreiche Reports und Analysen ist es sicherlich sinnvoll aufbereitete Daten in der "Breite" bereitzuhalten (Stichwort: Datawarehousing), aber für das grundlegende Modell eines "lebenden" Systems würde ich das NIE empfehlen.

Gruß Fal

[Mario Rosenbohm]

Hallo Falk,

... genau so sehe ich das auch.

Ich denke wir werden wohl oder übel die DB mal mit ein paar Mio DS füllen und dann mal einige Selects testen.

Gruß Mari