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.
Notwendig sind sie heufiger als man denkt. Gerade wenn man auch die Performance und die Systemresourcen
im Auge hat.
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.
Ich habe nicht gesagt, das Joins Hexenwerk sind. Ein gutes und stimmiges Modell macht auch viele Joins (die in anderen Modellen notwendig sind), überflüssig. Man sollte aber auch daran Denken, das ein Datenmodell, so gut es auch entwickelt wurde, selten die 2. Version überlebt.
Fakt ist aber, das Joins eine
DB (bzw. den Server) stark belassten (hinsichtlich Performance und Systemresource). Mit steigernder Nutzerzahl wird das sicher relevant.
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.
