Sichten

[Lude]

Hi,

ich meditiere seit laengerem ueber den Sinn von Sichten. Klar, wenn man mehrere Tabellen hat, die logisch zusammengehoeren (Beispiel: 'Users', 'Rights' und 'Sessions' (drei Tabellen um Sicherheit zu implementieren)), dann kann man eine Sicht 'View_Session' erstellen und diese die Sessions mit ihren eingeloggten Benutzern und deren Rechten als eine Datensatzmenge darstellen lassen. - Reicht das als Existenzberechtigung fuer Sichten? (Man behalte in Erinnerung, dass "eine Sicht mehr" auch ein mehr an Komplexitaet mit sich bringt.)

Der andere Grund fuer den Einsatz von Sichten schien mir die Schnittstellenbildung zu sein, also man "datengreift" z.B. grundsatzlich nicht auf die Datenbanktabellen, sondern nur auf die "Schnittstellenschicht" (also die Sichten, die ggf. auf jeder Tabellen liegen) zu. Dann koennte man Aenderungen am Datenmodell machen ohne dass die Datenzugriffsprozeduren das merken. Das waere gut. - Ist das die offizielle Existenzberechtigung fuer Sichten?

Oder gibt's noch weitere Vorteile der Sichten?

Gruss,
Lude

[Cheatah]

Hi,

ich meditiere seit laengerem ueber den Sinn von Sichten.

ist das die Übersetzung von "View"?

Klar, wenn man mehrere Tabellen hat, [...]

Auch. Ein View ist im Grunde nichts anderes als ein Subselect, den zu notieren man sich spart.

Der andere Grund fuer den Einsatz von Sichten schien mir die Schnittstellenbildung zu sein,

Das würde ich als den großen Vorteil von Views ansehen; letztlich ist das genaue Datenbank-Schema nicht von Relevanz, wenn es bestimmten Zwecken dient, die über einheitliche Produkte angefordert werden.

Oder gibt's noch weitere Vorteile der Sichten?

Sagen wir es so: Einige mir bekannte DB-Experten versuchen alles nur mögliche, um den Einsatz von Views zu vermeiden.

Cheatah

[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

[Lude]

Hi,

danke fuer Eure Ausfuehrungen. - Eine kurze und eine lange.   ;-)

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.

Meine Rechnung, dass mehr Objekte immer auch mehr Komplexitaet bedeuten, scheint widerlegt?

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 ...

Das wuerde gehen. Sicherheit ueber Sichten zu implementieren kommt in Betracht, hat aber sicherlich seine Nachteile, weil Sicherheit, wie Du ausfuehrst, nicht alleine ueber Sichten implementiert werden kann.

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).

Bei dieser Gelegenheit wuerde ich gerne Eure Mitteilungsbereitschaft ausnutzen und nach Triggern fragen, die ja beispielsweise Datenhistorisierung unterstuetzen. - Darf ich auf Eure Meinung zu diesen Objekten hoffen?

Gruss,
Lude

[Michael Schröpl]

Hi Lude,

Meine Rechnung, dass mehr Objekte immer auch mehr Komplexitaet bedeuten, scheint widerlegt?

Für wen? - Darüberhinaus hat das Informatiker-Prinzip "divide et impera" auch hier Gültigkeit.

Das wuerde gehen. Sicherheit ueber Sichten zu implementieren kommt in Betracht, hat aber sicherlich seine Nachteile, weil Sicherheit, wie Du ausfuehrst, nicht alleine ueber Sichten implementiert werden kann.

Die Sicherheit selbst wird natürlich über GRANTs implementiert.
Was ich im Moment nicht weiß, ist, ob man einer View (bzw. der Userid, welche diese View definiert hat) andere (d. h. mehr) Zugriffsrechte geben kann als dem "Endbenutzer", so daß dieser bei Verwendung der View auf eine Tabelle zugreifen könnte, die er direkt gar nicht ansprechen darf ...

Bei dieser Gelegenheit wuerde ich gerne Eure Mitteilungsbereitschaft ausnutzen und nach Triggern fragen, die ja beispielsweise Datenhistorisierung unterstuetzen. - Darf ich auf Eure Meinung zu diesen Objekten hoffen?

Trigger (vor allem in Kombination mit stored procedures) erlauben Dir, Aktionen durchzuführen, die z. B. für die logische Konsistenz des Datenmodells erforderlich sind, aber nicht alleine durch "statische" SQL-Mittel (UNIQUE, constraints etc.) modellierbar sind. Auch Einsatzfälle wie die zuverlässige Protokollierung bestimmter Vorgänge ließe sich so weit innen in bequemer Weise implementieren.
Die Verlagerung der entsprechenden Mechanismen in Anwendungsprogramme würde a) ggf. zu Code-Duplizierung führen und b) entsprechende Mechanismen leicht umgehbar machen (insbesondere dann, wenn man ab und zu doch mal über die Kommandozeile geht ...). Viele Datenbank-Anwendungen nutzen keinen Authentifizierungsmechanismus, der über das reine Login hinausgeht; tut man dies aber doch (GRANTs, Rollen-Konzept), dann sollte man Trigger als Mechanismus "im Hinterkopf haben".

Trigger sind letzten Endes also "Eventhandler" innerhalb der Datenbank, oder auch User Exits - es gibt durchaus Einsatzfälle, in denen sie die beste, wenn nicht einzige Lösung eines bestimmten Problems darstellen können.

Viele Grüße
      Michael