unique Keys, mehrere Tabellen oder was ?

[Hansa]

Hi,

man sehe sich mal folgende Tabelle an (es geht darum, statistische artikelgenaue Umsatzzahlen pro Kunde zu speichern) :

SQL-Code:

CREATE TABLE KUARTSTAT (
    ID               INTEGER NOT NULL,
    ID_KUNDE         INTEGER,
    ID_ART           INTEGER,
    MONAT            SMALLINT NOT NULL,
    JAHR             SMALLINT NOT NULL,
    UMSATZ           DECIMAL(15,2),
...
    GRATIS           CHAR(1),
);

Zuerst wollte ich einen unique key generieren, bestehend aus ID_KUNDE, ID_ART, Monat und Jahr. Das wären schon 4 Felder. Jetzt ist mir noch das Feld GRATIS aufgefallen. Ich will ja auch noch sehen, wieviel vom Umsatz der sogar gratis gekriegt hat. 8) und es ist noch ein ähnliches Feld da.

Soll ich nun den unique aus 6 Feldern aufbauen, oder aber noch mehr Tabellen ? Wo sind jetzt die Vor- und Nachteile ?

[Alfons_G]

Hallo Hansa,

das kann man so nicht einfach sagen - jede Datenbank optimiert anders. Der Unique Key hat ja den Vorteil, dass es unmöglich wird, zwei übereinstimmende Datensätze einzufügen. Wenn es möglich ist, dass es in einem Monat zwei Datensätze im selben Monat zum selben Kunden gibt - gratis und gegen Bares - dann musst Du das Feld dazu nehmen. Das Einfügen der Daten wird natürlich immer langsamer, je mehr Felder Du zum Key dazufügst.
Mehrere Tabellen lösen dieses Problem auch nicht, denn dann hast Du mehrere Insert-Operationen, die mehrere, wenn auch einfachere Keys aktualisieren müssen.
Zum Suchen in en Daten solltest Du ohnehin noch zusätzliche Indizes auf die üblichen Suchkriterien (vermutlich Jahr/Monat, ID_ART und ID_Kunde) erstellen. Das Gratis-Feld brauchst Du normalerweise nicht indizieren. Zumindest bei Oracle ist ein Index erst bei einer dreistelligen Zahl unterschiedlicher Werte in einem Feld wirklich sinnvoll.

Am besten wäre vielleicht, Du würdest die Tabelle mal per Programm mit einigen 10000 Datensätzen füllen und dann mal die Performace mit Einfüge- und Abfrage-Operationen testen.

:coder:

[Hansa]

Ich habe mir das ganze nochmals überlegt. Ich werde folgendes tun : 2. Tabelle anlegen. Und zwar wegen folgender Überlegungen : der gratis-Anteil liegt wohl unter 1%. Würde ich die Tabelle so lassen und einen unique Key verwenden, dann hätte ich folgende Nachteile : ein gratis Feld im Datensatz. Dieses Feld müßte auch im unique Key mitgeschleppt werden. In über 99 % der Fälle gar nicht nötig. Ein Insert in 1 % der Fälle in andere Tabelle fällt kaum ins Gewicht.

Allerdings ist der Hauptgrund ein praktischer. Was nützt es, zu wissen, in 9/2004 hat ein Kunde 10 Stück gratis erhalten. Der entgangene Umsatz und Rohgewinn in diesem Monat ist x EUR usw. Gut wäre es auch noch zu wissen, wann das genau war, also auch an welchem Tag und vielleicht noch die Beleg-Nr. Spätestens jetzt ist die bestehende Tabelle aber am Ende, denn den Tag kann ich unmöglich da noch unterbringen. Das wäre völlig unübersichtlich.

Dies bedeutet dann für die Gratis-Tabelle folgendes :

SQL-Code:

CREATE TABLE KUARTGRATIS (
    ID               INTEGER NOT NULL,
    ID_KUNDE         INTEGER,
    ID_ART           INTEGER,
    REDATUM          DATE,
    RENR             INTEGER,
    MENGE            INTEGER,
... Umsatz, Rohgewinn ??? 
);

In den unique Key dieser Tabelle müßte dann rein : ID_KUNDE,ID_ART, RENR. Letzeres statt des Rechn.Datum, da nich ausgeschlossen werden kann, daß 2 Gratis-Lieferungen wegen geringen Lagerbestandes vielleicht einmal an einem Tag erfolgen. Müßte doch so gehen, oder habe ich was übersehen ?