1. Die Normalform ist zwar schön und gut, und sollte durchaus auch angestrebt werden. Aber in der Praxis gibts
Situationen und Anforderungen, die Redundazen nicht nur angenehm sonder sogar notwendig machen.
Redundanzen sind nie "angenehm". Der Rest stimmt nur, wenn man mit dBase oder
Paradox arbeitet. Für moderne
DB-Systeme gilt das zu 99,999% nicht. Redundanzen mögen beim lesenden Zugriff hilfreich sein, dafür hat man beim Schreiben höheren Aufwand. Die Diskussion über die Normalformen ist wie die um Patterns: Sinnvoll. Berücksichtigen. Immer. Muss man abweichen, hat man was nicht verstanden.
2. Joins...sie sind angenehm für den Programmierer. Aber sie erzeugen auch u.U. sehr hohe Lasten auf der
DB (und ggf. auf dem Rechner für die
DB). Deshalb versuch ich sie grundsäzlich zu vermeiden.
Siehe oben - gilt für
mySql,
MSSQL, Oracle, FireBird, etc nicht. Ein Join über mehrere Tabellen mit brauchbaren Indices belastet den Rechner für die
DB gar nicht. Siehe immer auch Execution Plan.
3. Die Strukturen immer so einfach wie möglich halten. Je einfacher das Datenmodell desto leichter ist es,
sie in einem Programm zu handhaben (xtCommerce ist da nicht gerade Vorreiter).
Naja, aber was heißt schon "einfach"? Es gibt effiziente und elegante Lösungen, die weniger "einfach" sind und scheinbar einfache Lösungen, die rasch sehr ineffizient werden. Aber wenn man sich an die drei Normalformen hält, ist man eh schon sehr gut bedient.