Firebird Embedded + AUTOINC

[himitsu]

Zitat von Perlsau:

Man sieht, das ist letztendlich einfacher zusammenzubauen als ein komplizierter SQL-Befehl in deiner Anwendung.

Nee, nix einfacher ... es ist genau das Selbe.
Einfach das CREATE VIEW ... AS weglassen und schon hat man das selbe SELECT-Statement, welches man direkt im Programm verwenden kann.

Zitat von Perlsau:

Ein weiterer Vorteil von Views besteht darin, daß ich in einer Query, die eine View-Datenmenge selektiert, direkt auch nach den Inhalten der verlinkten Sub-Tabellen sortieren kann, z.B.:

Und das Sortieren geht natürlich auch ohne VIEW problemlos ... bzw. es hätte auch mit einem VIEW nicht funktioniert, wenn man, so wie ich, in der Query-Komponente nochmal eine andere Sortierung drüber jagt.

[p80286]

Äh Entschuldigung *hust*
der Aufwand für einen/eine (?) View ist natürlich nicht kleiner als für eine "normale" query. Aber (wenn man's richtig macht) dann ist sie getestet und getestet und getestet ... und mit einem einfachen select ... from V_OpenInvoices bekommt man was man will, da braucht's nicht bei jedem Aufruf wieder diese ToDate(to_char(to_date....)) frickelei, oder was auch immer an Effekten zu beachten ist.

Gruß
K-H

[Perlsau]

Zitat von himitsu:

Und das Sortieren geht natürlich auch ohne VIEW problemlos ...

Natürlicht geht das auch ohne View problemlos, aber es ist – meiner Ansicht und Erfahrung nach – einfacher, wenn man alle Spalten bereits mit Spaltennahmen vorliegen hat, statt sie in der Sortiermethode nochmal alle einzeln angeben zu müssen. Du kannst auf diese Weise auch Views in ein anderes View einbauen, so daß du auch auf Felder von Sub-Sub-Tabellen zugreifen kannst.

Zitat von himitsu:

... bzw. es hätte auch mit einem VIEW nicht funktioniert, wenn man, so wie ich, in der Query-Komponente nochmal eine andere Sortierung drüber jagt.

Genau das mache ich doch auch in der oben auszugsweise dargestellten Sortier-Methode, die z.B. aufgerufen wird, wenn der Anwender auf eine Titelspalte klickt. Im View selbst wird bei mir gar keine Sortierung vorgenommen, das erledigt immer die Sortiermethode, die je nach ausgewählter Spalte das Property IndexFieldNames setzt. Natürlich kannst du jetzt einfach behaupten, das würde nicht funktionieren; bei mir jedenfalls funktioniert das genau so: Ich "jage" im Query, das die View-Datenmenge beherbergt, sozusagen auch eine andere Sortierung drüber

Will sagen: Ich verstehe deinen Einwand nicht wirklich

Zitat von p80286:

Äh Entschuldigung *hust*

Hier hast du ein Fishermen's extra stark

Zitat von p80286:

der Aufwand für einen/eine (?) View ist natürlich nicht kleiner als für eine "normale" query. Aber (wenn man's richtig macht) dann ist sie getestet und getestet und getestet ... und mit einem einfachen select ... from V_OpenInvoices bekommt man was man will, da braucht's nicht bei jedem Aufruf wieder diese ToDate(to_char(to_date....)) frickelei, oder was auch immer an Effekten zu beachten ist.

Nicht einfacher und dann doch einfacher Genau so ist es: "... und mit einem einfachen select ... from V_OpenInvoices bekommt man was man will, da braucht's nicht bei jedem Aufruf wieder diese ToDate(to_char(to_date....)) frickelei ...".

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