nicht angemeldet
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