Separate Tabellen mit indizierten Spalten???

[romber]

Hallo!

Ich habe von einem Bekannten gerade einen Tipp bekommen, im Rahmen der Normalisierung jede indizierte Spalte in eine separate Tabelle auszulagern, Indizieren und 1:n mit der Haupttabelle verknüpfen. Diese Aktion soll bei großen Tabellen angeblich enormen Performance-Schub leisten, besonders wenn es für den künftigen Abfragen nicht immer alle indizierte Spalten einezogen werden. So habe ich es verstanden. Ist was dran? Sollte man das wirklic machen?

[mkinzler]

In der Praxis muss man genau Ausloten in wiefern eine Normalisierung Sinn macht.
Die Theorie sagt ja, dass jedes Feld, dass nicht vom Schlüssel sondern von einem anderen Feld abhängt normalisiert werden muss. In der Praxis hängt es davon ab ob es bei Abfragen benötigt wird.

Nach der Theorie müsste ein Ort ausgelagert werden, da er ja vollständig von der PLZ abhängt, diese wird aber selten ohne den Ort benötigt, so dass in einer Abfrage nun ein "teuere" Join notwendig wird.

[romber]

Brrr..., habe nicht ganz verstanden.
Ich habe hier z.B. eine Tabelle mit den Ersatzteilen für die Landmaschienen. Da habe ich zwei Felder "Typ" und "Bauart", beide werden gelegentlich für die Suche verwendet. Bauart hängt immer vom Typ ab. Ein Index fasst beide Felder zusammen. Soll ich etwa diese beide Felder in eine separate Tabelle auslagern?

[sx2008]

Zitat von romber:

Bauart hängt immer vom Typ ab.

In den Fall sollte man eine Tabelle "LandMaschinenTyp" haben, bei dem der Typ der Primärschlüssel ist:

Code:

IdTyp | Beschreibung  | Bauart
====================================
    A | Traktor       | Allradantrieb
    B | Traktor       | Heckantrieb
    C | Vollernter    | Allradantrieb

Also ich habe kein Detailwissen über Landmaschinen, sodass die Beispieleinträge hier rein fiktiv sind.
Aber ich denke das Prinzip sollte klar werden.
In deiner Tabelle mit den Landmaschinen verweisst du mit einem Fremdschlüssel nur auf den Typ.
Damit ist die Bauart automatisch über die Tabelle "LandMaschinenTyp" festgelegt.
Du kannst auch die Bauart über eine weitere Tabelle auslagern:

Code:

Tabelle "LandMaschinenTyp
IdTyp | Beschreibung  | IdBauart
====================================
    A | Traktor       | 1
    B | Traktor       | 2
    C | Vollernter    | 1



Tabelle "Bauart"
IdBauart | Beschreibung
=======================
       1 | Allradantrieb
       2 | Heckantrieb

[mkinzler]

Zitat:

Brrr..., habe nicht ganz verstanden.

In der Theorie müsste man PLZ und Ort in eine eigene Tabelle auslagern, da der Ort vollständig von der PLZ abhängt. Da man in der Praxis in den meisten Fällen den Ort zusätzlich benötigt ist die Normalisierung in diesem Fall kontraproduktiv.

[FredlFesl]

Zitat von romber:

Hallo!

Ich habe von einem Bekannten gerade einen Tipp bekommen...Diese Aktion soll bei großen Tabellen angeblich enormen Performance-Schub leisten

Nein! Die schnellste Datenbank ist die, die überhaupt keine Verknüpfungen hat, d.h. nur aus einer einzigen Tabelle besteht.

Wobei ich mit 'Datenbank' hier eher 'Information' meine, also z.B. 'Lagerbestand', 'Kundenaufträge' usw.

Stichwort: Data Warehouse.

Mit normalisierten Datenbanken spart man Speicherplatz, weil man Redundanz vermeidet.

I.A. ist die Architektur so, das man für laufende Prozesse (offene Aufträge, aktuelle Produktionsdaten usw) eine normalisierte Tabelle verwendet und für die Statistiken ein Datastore / Datawarehouse, also alles in eine Tabelle stopft. Einige wenige Daten dürfen dann in einer Lookuptabelle sein, z.B. Datumsinformationen (Datum, Tag, Monat, Quartal, Jahr, Wochentag usw.)

[mkinzler]

Zitat:

Nein! Die schnellste Datenbank ist die, die überhaupt keine Verknüpfungen hat, d.h. nur aus einer einzigen Tabelle besteht.

Wenn man alle Informationen benötigt.
Zudem ist es wenig klug, Redundanzen zu zu erzeugen.

[Union]

Das die Abfrage eine Datenmenge einer Tabelle mit wenigen Felder evtl. schneller ist sieht wie ein Vorteil aus. Bei einer stark normalisierten Form stehen dem als Nachteil aber die vielen benötigten JOIN entgegen. Bei den heutigen hochoptimierten (und teilweise sich selbst optimierenden) Datenbanken kann man den richtigen Mittelweg nur durch Ausprobieren und Performancemessungen herausfinden. Wichtig ist auch der Performance-Schwerpunkt, ist diese bei INSERT, SELECT, UPDATE oder überall wichtig?

[romber]

Vielen Dank für diese hilfreiche Antworten! Ich fange langsam an, das ganze zu verstehen. Falls eine oder andere Anfängerfrage euch, den Profis, doof vorkommt, so bitte ich vorab um Verzeihung.

Zitat von sx2008:

In den Fall sollte man eine Tabelle "LandMaschinenTyp" haben, bei dem der Typ der Primärschlüssel ist

Ist Primärschlüssel nicht eindeutig? Ich meine, es werden doch immer wieder die gleichen Typen der Tabelle hinzugefügt.

Zitat von mkinzler:

In der Theorie müsste man PLZ und Ort in eine eigene Tabelle auslagern, da der Ort vollständig von der PLZ abhängt. Da man in der Praxis in den meisten Fällen den Ort zusätzlich benötigt ist die Normalisierung in diesem Fall kontraproduktiv.

In meiner Tabelle gibts es praktisch nur zwei Abhängigkeiten:
- "Bauart" hängt vom "Typ" ab. In 70% aller Abfragen braucht man davon nur den Typ.
- "Baujahr-Monat" von "Baujahr-Jahr". Auch hier braucht man in der Regel nur das Jahr.

Alle anderen Felder haben keine Abhängigkeiten voneinander. Es gibt auch keine vorgebenen Abfragemuster. Der Benutzer hat eine Suchmaske und kann die Parameter beliebig auswählen. Die Parameter entsprechen den Tabellenfeldern. Die Ausnahmen sind eben diese viel o.g. Parameter. Um Bauart auszuwählen, muss der Benutzer zuerst den Typ wählen, genau so bei Monat und Jahr. Ansonsten frei Wahl der Suchlarameter. Ich möchte bei den Abragen die bestmögliche Performance erreichen.

Zitat von Union:

Wichtig ist auch der Performance-Schwerpunkt, ist diese bei INSERT, SELECT, UPDATE oder überall wichtig?

INSERT und UPDATE sind egal, SELECT ist das wichtigste.

Was würdet Ihr mir empfehlen? Soll ich die Felder auslagern oder nicht?