nicht angemeldet
yo,
Gut, dann aendere ich die dort eingetragene, auf eine bestimmte Rechnungsadresse referenziernde ID im nachhinein also nicht mehr.
Dann wird in der Adresshistorie also nicht editiert, sondern hoechstens hinzufuegend korrigiert (neuer Datensatz mit korrekter Adresse).
grundsätzlich ist es so, dass man viele möglichkeiten hat, sein daten-design zu entwickeln. so ist es durchaus denkbar, vieles mit nur einer tabelle abzubilden. und auch dein weg würde funktionieren, wenn man bestimmte regeln einführt und sich daran hält.
die frage ist aber, welches ist ein optimales design für meine individuelle umgebung. mal davon abgesehen, dass sich darüber vortrefflich streiten läßt, ohne jemals zu einem gemeinsamen ergebniss kommen zu müssen, ist die normalsierung ein weg, zu diesem ziel zu gelangen. es ist kein muss, aber oftmals doch ein guter ratgeber. man darf sich also nicht nur von der frage leiten lassen, ob etwas geht, viele wege führen nach rom. vielmehr interessiert die frage, was ist das beste design für mich.
und was du vorschlägst verstösst meiner meinung nach gegen die normalisierung, wobei ich nicht alle "hunderte" regeln kenne, aber bleiben wir mal bei den ersten 3, bzw. 4. wie gesagt modeliert man ja nach abhängigkeiten. und du lagerst etwas aus, was zur entität dokument/rechnung gehört. damit es dann wieder funktioniert und du dir keine anomalien einhandelst, musst du zusätzlich bestimmte regelungen einführen, die du dann in jeder applikation implementieren musst, bzw. du musst dich ja auch davor schützen, dass jemand das direkt auf datenbank-ebene macht.
wie gesagt würde das gehen, aber ist das wirklich ein -> mehrgewinn <- für mich oder doch eher ein nachteil ? ich würde natürlich sagen letzteres. man muss zusätzlich regeln beachten, die man eigentlich gar nicht beachten will oder bräuchte, wenn ich es anderes modelieren würde.
lass mich mal ein anderes beispiel anführen, was genau das gleiche macht wie dein vorschlag. stell dir eine einfache kundentabelle vor. dort gibt es unter anderem den nachnamen der kunden. nun kommen die meiers und die müllers als name schon mal öfters vor. also kommt ein mitarbeiter auf die idee, die nachnamen in eine extra tabelle auszulagern und darauf dann entsprechend zu referenzieren. auch dafür würde ich keinen grund sehen, das zu tun, ich hole mir damit nur einen nachteil in das boot.
und um es noch ein wenig auf die spitze zu treiben, selbst wenn meine vorgabe ist, eine extra tabelle mit nachnamen zu führen, die alle möglichen nachnamen enthält, aus denen dann ein nachname ausgewählt werden muss, selbst dann würde ich nicht über einen fremdschlüssel darauf referenzieren, sondern es fest persistieren. die begründung dafür ist immer die die gleiche, nämlich die abhängikeit des nachnames zu der person.
ich würde ja eine kontrolle durch die auslagerung schaffen, wo ich dann mit zusätzlichen regeln dafür sorgen muss, dass diese kontrolle gar nicht benutzt werden darf. oder um es mal umgangssprachlich auszudücken, ich kaufe mir ja nicht etwas, was ich dann gar nicht benutzen darf, weil es mir schaden zufügen könnte.
Wie gesagt, kenne ich aus den Datenmodellen im SAP-Umfeld anders.
auch SAP kocht nur mit wasser ;-)
Ilja