Sichten

[Michael Schröpl]

Hi Lude,

Reicht das als Existenzberechtigung fuer Sichten? (Man behalte in Erinnerung, dass "eine Sicht mehr" auch ein mehr an Komplexitaet mit sich bringt.)

mehr Komplexität für den DDL-Macher, aber weniger Komplexität für den DML-Macher.
In gewisser Hinsicht verbirgst Du Dein tatsächliches Datenmodell und erlaubst es den "Anwendern" dadurch, für spezielle (häufig vorkommende) Zugriffe einfachere, verständlichere SQL-Statements zu formulieren.

Dann koennte man Aenderungen am Datenmodell machen ohne dass die Datenzugriffsprozeduren das merken. Das waere gut.

Hm - für Lesezugriffe mag das gelten, für Schreibzugriffe nicht. Und wenn sich das Datenmodell tatsächlich ändert, dann bietet es üblicherweise neue Möglichkeiten, die sich früher oder später in entsprechenden Änderungen der Zugriffslogik niederschlagen müssen.

Ganz zu schweigen von zusätzlichen _Anforderungen_, die mit einer Änderung des Datenmodells entstehen. Das Problem von Views ist, daß man damit prima lesen kann, nicht aber prima schreiben (weil eine View auch ein JOIN mehrerer Tabellen sein kann).
Und schon für eine View auf nur einer einzigen Tabelle könnte es erforderlich sein, nach einer Änderung des Datenmodells eine zusätzliche Spalte beim Schreiben (Einfügen) mit Daten versorgen zu _müssen_ (weil deren Semantik zu komplex ist, um über einen Defaultwert versorgt zu werden).

Oder gibt's noch weitere Vorteile der Sichten?

Was ich selbst noch nicht versucht habe, das ist der Aspekt der Berechtigungen.
Möglicherweise kann man nicht nur Benutzerkennungen, sondern sogar Views berechtigen, auf Tabellen zuzugreifen? In diesem Falle könnte man verschiedenen Applikationen beispielsweise unterschiedliche Mengen von _Zeilen_ derselben Tabelle zugänglich machen ...
Wir haben Views damals eingesetzt, um historische Sichten eines Datenbestands zu implementieren, mit Gültigkeitsintervallen - ganz ähnlich wie in einem erst kürzlich hier im Forum erschienenen Thread. Hierbei filterten die verschiedenen Views z. T. sowohl Zeilen als auch Spalten (die "heute"-Sicht des Datenbestandes, beispielsweise).

Ich denke, Views bieten vor allem ein Komfort-AddOn für Benutzer, die SQL so verwenden, wie es wahrscheinlich ursprünglich mal gedacht war: Nicht als Sprache, die von 3GL-Applikationen über eine Funktions-API angesprochen wird, sondern als Sprache, die man über ein Kommandozeilen-API bedient und dabei direkt Queries im Dialog eintippt.
Denn _dafür_ ist die 4GL-Eigenschaft von SQL m. E. am besten geeignet: Anwendern ohne "algorithmische" Kenntnisse zu erlauben, mit einer flexiblen und mächtigen "Programmiersprache" auf Daten zuzugreifen und diese sogar zu manipulieren. Ich selbst löse einige Probleme des Tagesgeschäfts mit dieser Methode, die einfach schneller geht, als jedes Mal extra ein Skript dafür zu schreiben und dafür die Bedienung der DBI::-API nachzuschlagen ... im Zeitalter der Klicki-Bunti-GUIs ist diese Idee anscheinend in Vergessenheit geraten (obwohl es auch GUIs gibt, mit denen man SQL-Statements interaktiv zusammenklicken kann).

Cheatahs (etwas unspezifisch formulierte ;-) Bedenken gegenüber Views kann ich insofern nachvollziehen, als SQL aus Performance-Sicht schon keine einfache Materie ist und eine unbedachte Verwendung von Views (z. B. ohne die Definition unterstützender Indexbäume) die Sache sehr leicht deutlich verschlechtern kann. Views zu definieren ist DDL, nicht DML, und sollte Leuten überlassen bleiben, die mehr können als nur SELECT-Statements formulieren.
Performance kann man teilweise sehr weit unten im Datenmodell unterstützen (Stichwort für Oracle: Tabellen-CLUSTER - das geht noch viel tiefer in die Materie als Indexbäume, wenn man schon die physikalische Anordnung der Datensatzspeicherung auf die späteren Tabellenzugriffe optimiert).

Viele Grüße
      Michael