nicht angemeldet
Hallo Verena,
Aber wäre das auch noch effizient wenn es 4000 Berufe und 20000 Personen wären?
Ja, gerade dann wäre es effizeint. Denn nicht jede der 20.000 Personen wird alle 4.000 Beruf haben. Dann bräuchtest Du ja keine Datenbank mehr *gg*
Mit dem normalisierten Modell wird ja nur immer dann ein Datensatz angelegt, wenn er benötigt wird, während in Deinem Modell (und auch beim Subtype SET) für jeden Beruf in jedem Personen-Datensatz ein Bit bereit gehalten werden muss. das steht dann entweder auf 0 oder 1.
Die Bit-Zuordnungstabelle würde bei 4.000 Berufen 500 Byte pro Person verschlingen. Die 4.000 Klartextübersetzungen, die ich in die Tabelle GetSkills gepackt habe, würdest Du auch benötigen. Sie würden etwa genauso viel Platz benötigen.
Ein Datensatz für HasSkills benötigt 24 Byte. Er setzt sich ja nur aus drei Schlüsseln zu je 8 Bytes (BigInt) zusammen. Da kann dann jeder 20 Datensätze haben, bis es mehr Speicherplatz kostet, als die Bitmuster-Variante. Den Primary-Key ID_HasSkills kann man auch weglassen, da ja ID_Person und ID_GetSkills zusammen einen Unique Key = Primärschlüssel geben. es ist ja nicht anzunehmen, dass eine Person eine Eigenschaft doppelt hat, oder? Dann könntst Du schon 31 Eigenschaften pro Person festhalten, bevor es mehr Speicherplatz als die Bitmustervariante kostet.
Nun zur Frage, welche ist die richtige. Ich gehe davon aus, dass die 4.000 bisher entdeckten Berufe auf lange Sicht nicht mehr werden. Das heißt, dass man bei der Bitmustervariante die Tabelle in der statischen Richtung (horinzontal) nicht anfassen muss.
Sollte die Zahl der Möglichkeiten aber dynamisch sein, (es kömmen welche hinzu, fallen wlche weg, ändern welche ihren Platz in der Reihenfolge), dann musst Du die in die dynamische Richtung der Tabelle legen, also in die Dateninhalte. Das würde für die Normalisierungsvariante sprechen.
Oder Variation zwei, das selbe in komprimierter Form
PERSON_ID | BERUFE ..........
0 | 0010..........
1 | 1010..........
2 | 0101..........
3 | 1001..........
4 | 1101..........
5 | 0000..........
6 | 1110..........
7 | 0001..........
Diese Variante ist ja im Prinzip die des "SET-Feldes". Du baust Dir einfach einen Blob oder ein xText-Feld und füllst es mit einem String, den Du natürlich vorher berechnen musst. Er enthält nur das Bitmuster.
Das Zusammenstellen der aus den 4000 möglichen ausgewählten Eigenschaften dauert dann allerdings etwas länger. Du musst dann ja z.B. von rechts nach links den String im Speicher byteweise lesen (bitweise geht nicht) und den Wert in einen Tabelleneintrag umwandeln. Da fällt mir im Moment nicht ein, wie man das bezüglich der Rechenzeit schnell gestalten könnte.
Und ein wesentlicher Punkt für das Design dürften die Abfragemöglichkeiten sein.
In C oder Pascal kann man auch Strings bitweise vergleichen. Ob es in PHP oder Perl eine Möglichkeit dazu gibt, weiß ich im Moment nicht.
(ich hoffe es wird klar was ich meine)
Ja, total.
Liebe Grüße aus http://www.braunschweig.de
Tom
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.