Firebird Embedded + AUTOINC

[mikhal]

Zumindest bei Oracle hat die View neben den bereits gelaufenen Tests und Optimierungen einen weiteren entscheidenden Vorteil: Sie liegt compiliert in der Datenbank, das heißt der Optimizer hat nichts mehr zu tun, die Daten werden sofort mit dem hinterlegten Abfrageplan abgerufen.

Grüße
Mikhal

[jobo]

Views können über das Genannte hinaus auch zur Definition und Einhaltung einer Interface-Schicht dienen, inklusive der entsprechenden Berechtigungen. Und wie bereits geschrieben bietet dieses Verfahren "nebenbei" eine komplette Abstraaktionsschicht. Das DB Modell darunter kann beliebig geändert werden, ohne das man der Anwendung ein Haar krümmen muss (und ohne deploy usw.)
Verfügt das RDBMS über ein halbwegs aufgeräumtes Repository (was idr so ist) hat man auch mit einer handvoll Abfragen alle Objektabhängigkeiten von der Anwendung bis zur Tabelle im Griff. Eine Modelländerung kann man also planerisch oder ad hoc oder wie auch immer jederzeit überschauen.

[Bernhard Geyer]

Zitat von mikhal:

Zumindest bei Oracle hat die View neben den bereits gelaufenen Tests und Optimierungen einen weiteren entscheidenden Vorteil: Sie liegt compiliert in der Datenbank, das heißt der Optimizer hat nichts mehr zu tun, die Daten werden sofort mit dem hinterlegten Abfrageplan abgerufen.

Macht der MS SQL Server genauso.
Mit dem "Vorteil" das bei Änderungen der zugrundeliegenden Datenbank der View ermals mit nicht nachvollziehbarer Fehlern abbricht - jedenfalls gabs das Problem mit älteren Versionen des Servers. Musste man dan händisch neu compilieren lassen.

[jobo]

Zitat von Bernhard Geyer:

Macht der MS SQL Server genauso.
Mit dem "Vorteil" das bei Änderungen der zugrundeliegenden Datenbank der View ermals mit nicht nachvollziehbarer Fehlern abbricht - jedenfalls gabs das Problem mit älteren Versionen des Servers. Musste man dan händisch neu compilieren lassen.

Automatische Recompilierung schafft Oracle leider auch nicht immer.
Aber immer öfter.

[p80286]

Zitat von jobo:

Automatische Recompilierung schafft Oracle leider auch nicht immer.
Aber immer öfter.

Jojo...

Zitat von Perlsau:

Nicht einfacher und dann doch einfacher

Da hast Du die zeitliche Abfolge vernachlässigt. Erst hat man den Aufwand, jeden ... zu berücksichtigen und danach geht's rubbel die Katz!

Und bitte nicht vergessen, es gibt Datenbanken, da kommt man als Benutzer nur an die Views heran.

Gruß
K-H

[mikhal]

Das Problem der neu zu compilierenden Views gibt es bei Oracle auch, wenn die Definitionen der zugrundeliegenden Tabellen geändert werden, das zieht sich aber durch über procedures und functions, Jobs, Trigger etc. Liegt wohl in der Natur der Sache.

Dass es Datenbanken gibt, bei denen der Benutzer nur die Views zu sehen bekommt, liegt wohl eher daran, dass der Benutzer ausschließlich die Rechte erhalten hat, Views zu verwenden. In Data Ware House Datenbanken war und ist das üblich, damit die Daten nicht verändert werden können.

Grüße
Mikhal

[Dejan Vu]

Probleme mit Views kenne ich bei einer View, die '*' verwendet, wobei die verwendete Tabelle in der Struktur erweitert/verändert wird.

Code:

CREATE VIEW View_WillBlowUp as
select * from Foobar

Ein Wort noch zu Views: Wer wiederverwendbaren Code schreibt, oder Clean-Code anwendet (also Codeteile durch Einbetten in eine kleine Methode dokumentiert), sollte auch Views, UDF und SP verwenden. Damit wird der SQL-Code einfach lesbarer. Wer Obfuscation liebt, der verwendet die natürlich nicht, ist ja klar.

Und wenn sich einmal die Definition der 'OpenInvoices' ändern sollte (bitte keine internen Rechnungen an die IT), dann macht man das an einer einzigen Stelle: Nämlich in der View. Und ab *sofort* sind alle Reports, Auswertungen und Programme angepasst und zeigen stringent die gleiche Information.

Allerdings ist die Verwendung einer View in extrem komplexen Queries (also wenn die Query selbst mit Views arbeitet) nicht immer schneller. Leider. Da muss man die View dann materialisieren und mit einem Index versehen, oder zu anderen Tricks greifen.