yo,
bekomm ich dann nicht Probleme mit meiner Formel, die ein Preis ausrechnet?
ändert sich das daten-design, ändern sich in aller regel auch alle abfragen und berechnungen. man muss sich nur bewußt sein, dass jedes design vor und nachteile hat und selten es das "perfekte" layout für alle fälle gibt. wichtig ist nur, dass man alle relevanten daten und beziehungen erfasst.
wenn sich bei einer Option oder bei ein Produkt ein Wert ändert, wird ein neuer aus den neuen Daten erstellt und der alte als inaktiv markiert, damit ich den alten Preis für ein bestehenden Auftrag berechnen kann.
ok, das ist eine neue erkenntnis. grundsätzlich sind datenbanken dafür konzepiert, die gegenwart einer entsprechenden umgebung widerzugeben. will man daten der vergangenheit mit ins spiel bringen, dann muss man ein paar besonderheiten beachten. fremdschlüssel, bzw. beziehungen können sich in punkto vergangenheit als hinderniss erweisen. stell dir eine kundentabelle vor und die zugehörige rechnung des kunden. ändert sich nun die adresse oder sogar der name des kunden und der verweis auf der rechnung wäre auf die kundentabelle, wäre das ein widerspruch, da die datenbank nur aktuelle daten enthält, nicht aber die vergangenheit. deswegen sollte man in rechung besser keine verweise auf andere tabellen haben, wenn diese sich ändern können, also direkt in der tabelle für rechnungen auch die damals aktuelle adresse, namen, etc. speichern. es handelt sich hierbei auch um keine redundanz, da diese daten sich ja eben nicht mitändern sollen, also unabhängig sind. das thema vergangenheit und datenbanken ist also recht komplex, man muss sich das bewußt machen, wie genau man die vergangeheit festhalten will.
wenn ich richtig überlege, würde ich ja Probleme bekommen, wenn jemand eine Option z.B. Farben löschen würde. Die Formel würde ja noch versuchen auf diese Teile zuzugreifen
sicherlich, das sind fälle, die man abdecken muss. ich würde wie gesagt vergangene dinge nicht durch beziehungen der gegenwart abhängig machen, sondern deren inhalte in extra tabellen speichern.
ich werde nicht ganz schlau aus deinem design, zumal ich mir das t am anfang der tabellennamen auch sparen würde. ich hätte erst einmal drei tabellen in kopf:
1. produkte
2. eigenschaften (farbe, gewicht, etc.)
3. produkte_eigenschaften
in der dritten tabelle würde dann auch die lieferzeiten stehen, dann ist es nämlich wirklich sowohl vom produkt als auch von der eigenschaft abhängig. ich habe also erst einmal nur drei tabellen.
Ilja