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.
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.
zu 1:
"Angenehm" an der Redundanz ist ja höchstens, dass "man" "es" als Programmierer (scheinbar) einfacher hat. Gerade im Sinne von Punkt 3. Wirklich "notwendig" sind sie wohl eher selten.
zu 2:
Joins sind kein Hexenwerk. Man kann in den allermeisten Fällen durch Indexierung und meist sinnvolle Einschränkungen der betrachteten Menge auf sehr "kleine" und schnelle Selectergebnisse kommen. Ich empfehle bei dem Modellentwurf nicht auf Anzahl von Joins abzuzielen, sondern auf ein stimmiges Modell. Gerade hier in dem Thread geht es ja offensichtlich um sehr gut beherrschbare Datenmengen.
3 ist sowieso empfehlenswert. In der Praxis macht man bei der Abbildung der Wirklichkeit immer irgendwo einen Cut, ein Kompromis aus Entwicklungsaufwand und gewünschten Ergebnissen, aber auch aus dem Eingabeaufwand, den das erstellte Modell erzwingt.
Wieviel Eingabemasken und Tabellen hat man schon gesehen, die aufwendig befüllt werden müssten, aber am Nutzen und Aufwand (Praktikabilität, Faulheit, Zeitdruck, ..) scheitern.