Also ein View frisst kein Brot und die Erfindung des Scrollens in Fenstern oder Paging gibt es schon länger.
Pflegeaufwand kannst Du auch so rechnen:
Wenn der View nicht da ist, wie oft muss irgendein "armer Tropf" diese Joins statt dessen zusammenbasteln?
Wie oft macht er es richtig? Oder falsch? Wo muss eine (oder mehrere) Anwendung überall geändert werden, wenn sie nicht den View benutzt, sondern 10 mal den gleichen Join mit unterschiedlichen Select Clauses?
..
Wenn Du einen View als definiertes Interface betrachtest, dass maximale Kontrolle der Anwendungen und der DB und der Daten erlaubt, dann wäre Deine Frage vielleicht schon beantwortet oder?
Und zur Übersichtlichkeit: Verwende konsistente Namen, wenn es um eine Art Perspektive geht, dann eben die Objekt-Namen im View aufnehmen in der entsprechenden Perspektive. Hier würde ich auch nicht mit kryptischen Kürzeln hantieren, die es kurz und knackig machen.
P.S.: Um den Gedanken des Interface noch etwas zu erweitern. Hier ist auch der Gedanke der Vollständigkeit nicht verkehrt. Ein Entwickler, die 1/3 seiner Daten in irgendwelchen Views findet und 2/3 in Tabellen, die er sich zusammenstricken muss, ist vielleicht nicht so effizient, wie jemand, der ein plausibles Set an Views hat, auch für "seltene" Fälle.
