srob: Abfrage o./u. Design-Problem: "Simulation" Nested Tables

Beitrag lesen

Hi lemats,

bei derart gelagerten Problemen habe ich mich in den vergangenen zwanzig Jahren häufig zu einer durchnormalisierten Lösung ähnlich Deinem Entwurf entschieden - und mich in jedem Fall früher oder später darüber schwarz geärgert. Diese Aufdröselung in drei oder mehr Tabellen, teilweise mit m:n-Relationen, führt zu komplexen, häufig mehrstufigen Abfragen, deren Performance bei wachsender Datenmenge überproportional zurückgeht und die Wahrung der referentiellen Integrität aufwendig macht. Im Nachhinein würde ich mich immer für eine Denormalisierung entschieden haben, häufig habe ich es mühsam am laufenden System tatsächlich vorgenommen - belohnt mit drastischer Performancesteigerung.

Solltest Du nicht tatsächlich _alle_ Sprachen - nach dem Etnologue zur Zeit 6.912 - erfassen müssen, so solltest Du die Vorteile einer Ein-Tabellen-Lösung mit sprach- und währungsspezifisch multiplen Spalten für Titel, Beschreibung, Preis etc. einmal abwägen...

hth Robert