Effizientes Datenbankdesign

[*Markus]

Hallo,

ich habe folgendes Problem:
Ich will ein Datenmodell erstellen, dass so konzipiert ist, welches möglichst "datenbankschonend" ist. Das Ganze muss zuerst für MySQL, später mal für PostgreSQL konzipiert sein. Dazu muss ich kurz die Anforderung erklären.
Eine im System eingeloggte Person hat gewisse Personenmerkmale, die über fest vorgegebene Werte ausgewählt werden konnten (Lookup-Tabellen, zB Augenfarbe: grüne, braun, blau, grün-braun).
Das System soll diese eingeloggte Person mit sämtlichen anderen in der Datenbank gespeicherten Personen vergleichen (natürlich mit gewissen Eingrenzungen), und dabei eine Art Übereinstimmungswert bilden, wodurch die eingeloggte Person weiß, wieviele Merkmale sie mit anderen in der DB befindlichen Personen gleich hat.
All diese Personeneigenschaften befinden sich pro Person natürlich in einer Art Fakt-Tabelle, wo immer nur die einzelnen Zahlenwerte zu den aus der Lookup-Tabelle stammenden Werte gespeichert werden.
An und für sich wäre die ganze Sache ja schon relativ effizient, da ich immer nur gewisse Zahlen auf Übereinstimmung überprüfen muss.
Gäbe es ev. eine noch bessere Lösung, sodass man eventuell pro Konstellation eien Art Hashwert hat und man nur mehr diese beiden Hashwerte vergleichen muss, d.h. ein Vergleich anstatt zB 10x5 verschiedene (als Beispiel steht 10 für die verschiedenen Eigeschaften, die man auswählen kann, und 5 für die einzelnen Werte pro Eigenschaft)?

Markus

[Hopsel]

Hi *Markus!

Klingt so, als würdest du mehrere Indexe anlegen wollen.

MfG H☼psel

[*Markus]

Hallo,

Klingt so, als würdest du mehrere Indexe anlegen wollen.

Gute Idee. Ich glaube auch kaum, dass es eine bessere Lösung gibt.

Markus

[Hopsel]

Hi *Markus!

Klingt so, als würdest du mehrere Indexe anlegen wollen.
Gute Idee. Ich glaube auch kaum, dass es eine bessere Lösung gibt.

Wozu auch. Der Index leistet schließlich genau das, was du möchtest.
Und da die Anwendung wesentlich mehr vergleichen als anlegen muss, erscheint mir diese Lösung optimal.

MfG H☼psel

[Ilja]

yo,

All diese Personeneigenschaften befinden sich pro Person natürlich in einer Art Fakt-Tabelle, wo immer nur die einzelnen Zahlenwerte zu den aus der Lookup-Tabelle stammenden Werte gespeichert werden.

das ist meiner ansicht nach keine gute idee, du solltest die werte fest persistieren und nicht auf die Lookup-Tabellen über einen Fremdschlüssel referenzieren.

Ilja

[*Markus]

Hallo,

All diese Personeneigenschaften befinden sich pro Person natürlich in einer Art Fakt-Tabelle, wo immer nur die einzelnen Zahlenwerte zu den aus der Lookup-Tabelle stammenden Werte gespeichert werden.

das ist meiner ansicht nach keine gute idee, du solltest die werte fest persistieren und nicht auf die Lookup-Tabellen über einen Fremdschlüssel referenzieren.

Ich verstehe aus zwei Gründen nicht warum das sinnvoll sein soll:

• Man arbeitet schließlich fast immer mit den Nummern (FKs), die ja bereits in der "Fakt"-Tabelle verwendet werde. Ab und zu müssen die Bezeichnungen zu diesen Nummern zwar ausgelesen werden, aber das passiert verhältnismäßig selten.

• Würde ich es so machen, könnte irgendetwas in diesen Feldern stehen. Das System muss aber unbedingt anhand von bekannten Werten Datensätze vergleichen. In diesem Fall wäre das nicht mehr möglich, da willkürliche Werte in diesen Feldern stehen könnten.

Markus

[Ilja]

yo,

eine gutes datendesign zu finden ist nicht einfach, zumal es "das richtige" und "das falsche" design eigentlich nicht gibt. man kann nur versuchen, für sich die vorteile den nachteilen überwiegen zu lassen. je nachdem wie gut einem das gelingt, kann man damit viel geld verdienen.....

• Man arbeitet schließlich fast immer mit den Nummern (FKs), die ja bereits in der "Fakt"-Tabelle verwendet werde. Ab und zu müssen die Bezeichnungen zu diesen Nummern zwar ausgelesen werden, aber das passiert verhältnismäßig selten.

ist weder ein grund dafür noch dagegen es fest zu persistieren. ich meinte nicht der performance wegen, dass du dort einen zusätzlichen join machen musst. die gründe liegen woanders, nämlich abhängigkeiten modellieren und somit auch kontrolle schaffen, bzw, diese kontrolle an der richtigen stelle zu schaffen.

• Würde ich es so machen, könnte irgendetwas in diesen Feldern stehen. Das System muss aber unbedingt anhand von bekannten Werten Datensätze vergleichen. In diesem Fall wäre das nicht mehr möglich, da willkürliche Werte in diesen Feldern stehen könnten.

das ist ein feature, kein bug. warum solltest du nicht mehr vergleichen können, die werte sind doch alle vorhanden, die du dafür brauchst. der benutzer wählt aus der Lookup tabelle eine augenfarbe aus, und der wert dieser farbe kann mit den fest persitierten daten verglichen werden, bzw. er bekommt ja selbst einen persitierten wert.

gehen wir einen schritt weiter, ich habe in der vergangenheit als augenfarbe silber ausgewählt. nun willst du, aus welchen gründen auch immer, silber nicht mehr zur auswahl stellen, sprich keinen eintrag in der lookup tabelle. löschen kannst du ihn nicht, da es ja noch einträge gibt, die darauf referenzieren. also müsstest du meine einmal vom benutzer festgelegt farbe ändern, was dann aber nicht mehr meiner augenfarbe entspricht, die ich mal ausgewählt habe.

die augenfarbe ist also von der person abhängig und nicht vond er lookup tabelle, genauso wie ich der vorname zu der person gehört. die tatsache, dass du den wertebereich aus einer tabelle vorgeben willst, das alleine ist noch nicht grund genug, die abhängigkeiten zu ändern.

Ilja

[*Markus]

Hallo,

es ist mir schon klar, dass es ev. passieren könnte, nicht alle Eigenschaften mit einer Lookup-Tabelle abzudecken, obwohl alles schon ziemlich lange geplant ist, und versucht wurde, möglichst viel durch auszuwählende Werte miteinzubeziehen.
Bei deiner Lösung müsste ich weiters darauf vertrauen, dass die Benutzer immer "richtig" schreiben, d.h. ein "grün" wäre nicht dasselbe wie "gruen". Weiters soll eine Mehrsprachigkeit realisiert werden. Dadurch sehe ich absolut keine andere Möglichkeit mehr, es so zu erstellen, wie es bereits geplant ist.
Bei Mehrsprachigkeit bedeutet der Wert 3 im DB-Feld "augenfarbe" zB einmal "blue" und einmal "blau".
Falls du dazu eine bessere Lösung hast, würde ich mich freuensie zu hören.

Markus

[Ilja]

yo,

es ist mir schon klar, dass es ev. passieren könnte, nicht alle Eigenschaften mit einer Lookup-Tabelle abzudecken, obwohl alles schon ziemlich lange geplant ist, und versucht wurde, möglichst viel durch auszuwählende Werte miteinzubeziehen.

das meinte ich nicht, deine lookup tabelle bleibt weiterhin bestehen, allerdings wird darauf nicht mehr referenziert. die lookup tabelle macht nur das, wofür sie da ist, nämlich als vorlage zu dienen.

Bei deiner Lösung müsste ich weiters darauf vertrauen, dass die Benutzer immer "richtig" schreiben, d.h. ein "grün" wäre nicht dasselbe wie "gruen".

nein, siehe oben, die lookup tabelle kann bestehen bleiben, damit stellst du die richtige schreibweise sicher. aber du persistierst nicht den fremdschlüssel, sondern eben den wert fest in die tabelle.

Weiters soll eine Mehrsprachigkeit realisiert werden. Dadurch sehe ich absolut keine andere Möglichkeit mehr, es so zu erstellen, wie es bereits geplant ist.

hier muss ich mal auf einen lieblingssatz zurückgreifen, den ich meinen arbeitskollegen und entwicklern immer sage. "was gleich aussieht, muss nicht gleich sein". in deinem falle bedeutet das, die lookup tabelle ist eine eigenständige sache, die gewählten werte der person eine andere. willst du die mehrsprachrigkeit mit einbauen, musst du die werte auslagern und über einen fremdschlüssel referenzieren, aber über eine/mehrere zusätzliche tabelle auslagern und nicht über die lookup-tabelle. fragt sich nur genau wie, es gibt dabei einiges zu beachten.

ich denke mal, du hattest vor, in der lookup-tabelle einfach soviel spalten hinzuzufügen, wie du sprachen hast. also für blau eine spalte für deutsch, eine für englisch, etc. das wäre aber fatal. jedensmal wenn du eine zusätzliche sprache hinzufügst, müsstest du das daten-design ändern und auch damit sehr wahrscheinlich auch die anwendung anpassen.

du musst also dafür sorgen, dass du zusätzliche sprachen hinzufügen kannst, ohne das design ändern zu müssen. eine andere frage ist noch, ob neue eigenschaften im laufe des lebenszyklus hinzukommen sollen, auch hier gibt es dann das problem der design-änderung. etwas kniffelig alles, aber das überlasse ich mal alles deiner fantasie. wie gesagt, gutes daten-design ist eine hohe kunst und sehr individuell.

Ilja

[*Markus]

Hallo,

das meinte ich nicht, deine lookup tabelle bleibt weiterhin bestehen, allerdings wird darauf nicht mehr referenziert. die lookup tabelle macht nur das, wofür sie da ist, nämlich als vorlage zu dienen.

Bei deiner Lösung müsste ich weiters darauf vertrauen, dass die Benutzer immer "richtig" schreiben, d.h. ein "grün" wäre nicht dasselbe wie "gruen".

nein, siehe oben, die lookup tabelle kann bestehen bleiben, damit stellst du die richtige schreibweise sicher. aber du persistierst nicht den fremdschlüssel, sondern eben den wert fest in die tabelle.

Interessanter Ansatz. Ich begreife aber leider noch immer nicht so ganz, warum das in diesem Fall eine gute Lösung ist.

Weiters soll eine Mehrsprachigkeit realisiert werden. Dadurch sehe ich absolut keine andere Möglichkeit mehr, es so zu erstellen, wie es bereits geplant ist.

hier muss ich mal auf einen lieblingssatz zurückgreifen, den ich meinen arbeitskollegen und entwicklern immer sage. "was gleich aussieht, muss nicht gleich sein". in deinem falle bedeutet das, die lookup tabelle ist eine eigenständige sache, die gewählten werte der person eine andere. willst du die mehrsprachrigkeit mit einbauen, musst du die werte auslagern und über einen fremdschlüssel referenzieren, aber über eine/mehrere zusätzliche tabelle auslagern und nicht über die lookup-tabelle. fragt sich nur genau wie, es gibt dabei einiges zu beachten.

ich denke mal, du hattest vor, in der lookup-tabelle einfach soviel spalten hinzuzufügen, wie du sprachen hast. also für blau eine spalte für deutsch, eine für englisch, etc. das wäre aber fatal. [...]

Eigentlich dachte ich daran, die Textbezeichnungen in einer separaten Tabelle aufzubewahren und jeden Wert eindeutig zu identifizieren indem ich diese irgendwie mit den Lookup-Tabellen verknüpfe, aber im Prinzip bin ich gerade dabei, mir das zu überlegen.

du musst also dafür sorgen, dass du zusätzliche sprachen hinzufügen kannst, ohne das design ändern zu müssen. eine andere frage ist noch, ob neue eigenschaften im laufe des lebenszyklus hinzukommen sollen, auch hier gibt es dann das problem der design-änderung. etwas kniffelig alles, aber das überlasse ich mal alles deiner fantasie. wie gesagt, gutes daten-design ist eine hohe kunst und sehr individuell.

Neue Eigenschaften werden kaum dazukommen. Dafür eher mehr Sprachen.
Mehrsprachigkeit sinnvoll zu modellieren ist offensichtlich wirklich nicht so einfach wie es scheint, v.a. wenn man all die anderen Integritäten beachten soll.

Markus

[Ilja]

yo,

Interessanter Ansatz. Ich begreife aber leider noch immer nicht so ganz, warum das in diesem Fall eine gute Lösung ist.

lass mich dir ein ähnliches beispiel geben, wo es vielleicht ein wenig klarer wird. ich hatte eine lange diskussion mit meinen chef. es ging um die mehrwertssteuer. auch da hatten wir eine eigene tabelle, wo die werte drinne standen, die dann unter anderem auf die rechnungsdokumente als fremdschlüsel abgelegt war.

auch dort habe ich darauf hingewiesen, dass man das so nicht machen sollte, weil die mehrwertssteuer einer rechnung abhängig von der rechnung selbst ist. alte dokumente sollten sich eben nicht verändern, wenn ich in der tabelle für die mehrwertssteuer einen wert verändere. sie dient wie in deinem falle nur als vorlage, nicht aber als referenzierter wert. es geht letztlich darum, abhängigkeiten zu erkennen und richtig zu modellieren.

Eigentlich dachte ich daran, die Textbezeichnungen in einer separaten Tabelle aufzubewahren und jeden Wert eindeutig zu identifizieren indem ich diese irgendwie mit den Lookup-Tabellen verknüpfe, aber im Prinzip bin ich gerade dabei, mir das zu überlegen.

eigentlich keine grosse sache, eine typische m:n beziehung. allerdings für die menge der eigenschaften kann das ganz schön verwirrend werden, müsste man sich mal genauer anschauen. auch ist zu überlegen, ob man nicht trotzdem die werte in eine sprache persistiert, zum beispiel englisch und mit hilfe dieses wertes die anderen dann ermitteln.

Ilja

[*Markus]

Hallo,

auch dort habe ich darauf hingewiesen, dass man das so nicht machen sollte, weil die mehrwertssteuer einer rechnung abhängig von der rechnung selbst ist. alte dokumente sollten sich eben nicht verändern, wenn ich in der tabelle für die mehrwertssteuer einen wert verändere. sie dient wie in deinem falle nur als vorlage, nicht aber als referenzierter wert. es geht letztlich darum, abhängigkeiten zu erkennen und richtig zu modellieren.

Ok, ich weiß jetzt was du meinst. Wir hatten einen ähnlichen Fall, wo man mit ständigen Preisschwankungen konfrontiert war, Rechnungen aber gesetzlich aufbewahrt werden mussten. Unsere Preistabelle würde deiner MWst-Tabelle entsprechen.
Wir haben das Problem dann so gelöst, dass wir zwar die Preistabelle mit einem FK behielten, wir aber ein weiteres Feld "Positionsverkaufspreis" in der Tabelle "Abo", die den Preis referenziert, verwendeten, um den gerade aktuellen Preis speichern zu können. Dadurch ist das Abo von den Preisschwankungen abgekoppelt und unveränderlich gespeichert.

In diesem Fall denke ich mir aber, dass das ein Overhead ist, den ich hier nicht brauche, denn würden neue Eigenschaften dazu kommen, wäre das einfach eine neue Zeile in der Lookup-Tabelle. Die alten Referenzen bleiben ja unverändert. Ich kann eben jetzt statt Werte von 1-5 Werte von 1-6 speichern.
Natürlich besteht die Gefahr, dass ich einen der Werte von 1-5 versehentlich ändern könnte, und somit sämtliche alte Einträge plötzlich eine andere Bedeutung haben. Würde ich den Wert direkt referenzieren, würde das Problem nicht entstehen, da der Wert trotzdem irgendwo in der Lookup-Tabelle steht, und stets eine gültige Referenz ist.
Im Prinzip wäre es natürlich sinnvoller, es so zu machen. Allerdings ist mir jetzt noch die Mehrsprachigkeit ein Dorn im Auge. Die könnte mir dabei noch dazwischenpfuschen.

Eigentlich dachte ich daran, die Textbezeichnungen in einer separaten Tabelle aufzubewahren und jeden Wert eindeutig zu identifizieren indem ich diese irgendwie mit den Lookup-Tabellen verknüpfe, aber im Prinzip bin ich gerade dabei, mir das zu überlegen.

eigentlich keine grosse sache, eine typische m:n beziehung. allerdings für die menge der eigenschaften kann das ganz schön verwirrend werden, müsste man sich mal genauer anschauen. auch ist zu überlegen, ob man nicht trotzdem die werte in eine sprache persistiert, zum beispiel englisch und mit hilfe dieses wertes die anderen dann ermitteln.

Ok. Mal sehen, wie ich das in meinem Fall hinbekomme.

Markus

[Ilja]

yo,

Dadurch ist das Abo von den Preisschwankungen abgekoppelt und unveränderlich gespeichert.

mit dem preis für ein produkt verhält es sich ähnlich, man hat aktuelle preise für ein produkt, die sich ja immer wieder ändern, aber auf den alten rechnungen müssen natürlich die alten preise bestehen bleiben. das zeigt ziemlich deutlich die abhängigkeiten zu dem rechnungsdokument und nicht zu dem aktuellen preis aus der produkttabelle.

In diesem Fall denke ich mir aber, dass das ein Overhead ist, den ich hier nicht brauche, denn würden neue Eigenschaften dazu kommen, wäre das einfach eine neue Zeile in der Lookup-Tabelle. Die alten Referenzen bleiben ja unverändert. Ich kann eben jetzt statt Werte von 1-5 Werte von 1-6 speichern.

ich wäre mit dieser ansicht vorsichtig. bei deinen lookup tabellen hast du mit grosser wahrscheinlichkeit genau diese problematik. die lookup tabellen sollen die aktuellen werte anzeigen, die man auswählen kann. und das ändert sich auch mal, egal ob nun eine neue eigenschaft dazu kommt oder nicht. wie gesagt, tritt das problem schon auf, wenn du als augenfarbe früher mal silber hattest und es nicht mehr anbieten willst. dann treten typische anomalien auf.

die ausgewählten werte sind eben unabhängig von dieser lookup logik, sprich, wenn ich einmal augen in der farbe silber hatte, soll es auch so bleiben. mit einem fremdschlüssel auf die lookup tabelle bekommst du genau die gleichen probleme wie analog mit der märchensteuer oder den produktpreisen.

Ilja

[*Markus]

Hallo,

die ausgewählten werte sind eben unabhängig von dieser lookup logik, sprich, wenn ich einmal augen in der farbe silber hatte, soll es auch so bleiben. mit einem fremdschlüssel auf die lookup tabelle bekommst du genau die gleichen probleme wie analog mit der märchensteuer oder den produktpreisen.

Ok danke für deine Tipps. Ich glaube, dass du mich eigentlich schon überzeugt hast.

P.S: Märchensteuer? =)

Markus