Effizientes Datenbankdesign

[*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