nicht angemeldet
Man braucht keine Sichten.
...
So gesehen braucht man auch keine Datenbanken, man kann alles auch selber in einer Programmiersprache und ein paar Files umsetzen
So darf man nicht aber argumentieren. (Davon unabhängig: Datenbasen sind immer erforderlich, vermutlich meinst Du DBSe. Nun, ich kenne gute Datenhaltungen, die auf ISAM-Dateien basieren, aber Du weisst hoffentlich, warum SQL SQL heisst?)
Warum aber sind VIEWs böse? Nun, erst einmal haben wir eine zusätzlich eingezogene Schicht, die nicht benötigt wird. (Es kann bspw. bei eher wenig erfahrenen Entwicklern oft zu "Vers(ch)ichtungen" kommen, Sichten, die auf Sichten, die auf Sichten basieren. LOL)
Dafür gibt es Code Reviews ;-)
Keine Ahnung, ob Du das ernst meinst. (Falls ja: Designfehler sollte man nicht reviewen sondern vorbeugend per policies bearbeiten.)
Ein Beispiel wann Views sehr brauchbar sind sind historisierte Tabellen. Dann gibt es die Tabellen, die die gesamte Historie enthalten, und die Views, die nur die aktuell gültigen Werte zeigen.
Einspruch: Wir kennen zumindest zwei bessere Verfahren für die Historisierung, entweder spezielle History-DBs, die nicht mehr aktuelle Datensätze enthalten oder "n:m"s mit Versionierungen der Datensätze.
[1] Ebenso heisse Eisen wie die VIEWs sind bspw. die TRIGGER und die CASCADING DELETES, wobei es für Trigger immer hin noch den Anwendungsbereich "Alarmmeldungen" gibt.
Auch hier würde ich eine Historisierung der Daten als Beispiel nehmen. Kein Programmierer braucht sich Gedanken über das Historisierungskonzept zu machen, da dies automatisch bie DML-Aktionen durch die entsprechenden Trigger geschieht.
OK, Historisierung per Trigger haben wir auch mal umgesetzt. Würden wir nicht mehr so machen sondern stattdessen in den betreffenden DML-SPs Historisierungs-Code unterbringen. (Dann muss man bspw. auch nicht die ganzen Trigger ab- und zuschalten, wenn mal administrativer oder OLAP-Datenzugriff erfolgt. Schon mal das "vergessene Trigger-Problem" bearbeitet? (Oder das "vergessene FK-Problem"? ;))
Deine Argumentation erweckt den Eindruck, dass du diese Möglichkeiten ablehnst, weil jemand damit schlechte Anwendungen schreiben kann.
Da ist was dran. Man kann sicherlich ohne weiteres Spezialfälle konstruieren, in denen die angelieferten Objekte höchst geeignet sind. (Oft bei "Einmal-SW", die keinen echten Lebenszyklus hat. ;)
SW solte immer möglichst DAU-fähig sein.
Aber interessant, habe die VIEWs-Geschichte mit vielen Leuten diskutiert, fast alle versuchten aus mehr oder weniger bewussten Gründen VIEWs zu meiden.
apfelsine