Firebird Embedded + AUTOINC

[Hansa]

Views eleganter ? Dann erkläre mal bitte, wie ich die Daten einer Tabelle abrufe, sagen wir mal Artikel von Nr. 1 bis 1000 bestückt. Ich will aber jetzt aus meinem Delphi-Prograam nur die von 100 bis 199 sehen.

[himitsu]

Beim View kann man ja auch ein WHERE oder sowas wie LIMIT, STARTS usw. verwenden
und ein ordentliches DBMS kann das genau so schnell und optimal auflösen, als wenn man das SELECT direkt verwendet.
Der View ist logisch gesehen wie eine virtuelle Tabelle und lässt sich fast genauso verwenden. (nur beim Beschreiben trifft man auf die selben Probleme wie beim JOIN ... also wenn es um das zurückschreiben geht.)

Solange es kein Writable-View ist, kommt doch am Ende genau das Selbe raus ... nur mit nocheiner Zwischenschicht, die man erstmal schreiben muß.
Da ich diese Tabelle aktuell nur einmal benutze, ist es doch erstmal keine Vereinfachung.

[Dejan Vu]

Auch eine VIEW mit JOINs kann man beschreiben, wenn das RDBMS das unterstützt. Es muss sich nur jedes Feld der View auf ein Feld der darunterliegenden Tabelle abbilden lassen.

Natürlich muss ich eine VIEW entsprechend formulieren, wenn ich windowing funktionen verwenden, und dabei nicht ewig warten will. Ich persönlich find es es jedoch auch eleganter, eine Trennung einzuziehen und Zugriffe der Applikationen nur über Views und SP zuzulassen. Dann kann ich die DB-Struktur nach Herzenzlust ändern, ohne meine Programme anfassen zu müssen.

[Perlsau]

Zitat von Hansa:

Views eleganter ? Dann erkläre mal bitte, wie ich die Daten einer Tabelle abrufe, sagen wir mal Artikel von Nr. 1 bis 1000 bestückt. Ich will aber jetzt aus meinem Delphi-Prograam nur die von 100 bis 199 sehen.

Gerne, obwohl du das sicher auch selbst weißt, weil es so simpel ist:

Code:

select * from MyView where ArtikelNummer < 1001;
select * from MyView where ArtikelNummer > 99 and ArtikelNummer < 200;

In deiner Delphi-Anwendung arbeitest du dann mit Filtern, nachdem du im SQL-Property deiner Query-Komponente select * from MyView angegeben hast:

Delphi-Quellcode:

Datenmodul.Query_MyView.Filter := 'ArtikelNummer > 99 and ArtikelNummer < 200';
Datenmodul.Query_MyView.Filtered := True;

Einer meiner zahlreichen Views sieht z.B. so aus:

Code:

CREATE OR ALTER VIEW V_HOERBUCH(
    ID,
    TITEL,
    HOERART,
    AUTOR,
    KATEGORIE,
    SPRACHE,
    VORLESER,
    SPIELDAUER,
    ANZAHL,
    QUELLE,
    URL,
    GESEHEN,
    MARKIERT,
    NOTIZEN)
AS
select

HOERBUCH.ID_HOERBUCH,
HOERBUCH.TITEL,
BUCHSPIEL.HOERART,
AUTOREN.NAMEFULL,
KATEGORIEN.KATEGORIE,
SPRACHEN.SPRACHE,
VORLESER.NAMEFULL,
HOERBUCH.SPIELDAUER,
HOERBUCH.ANZAHL,
QUELLEN.QUELLE,
HOERBUCH.URL,
HOERBUCH.GESEHEN,
HOERBUCH.MARKIERT,
HOERBUCH.NOTIZEN

from HOERBUCH

inner join BUCHSPIEL  on BUCHSPIEL.ID_BUCHSPIEL   = HOERBUCH.HOERART
inner join AUTOREN    on AUTOREN.ID_AUTOREN       = HOERBUCH.AUTOR
inner join KATEGORIEN on KATEGORIEN.ID_KATEGORIEN = HOERBUCH.KATEGORIE
inner join SPRACHEN   on SPRACHEN.ID_SPRACHEN     = HOERBUCH.SPRACHE
inner join VORLESER   on VORLESER.ID_VORLESER     = HOERBUCH.VORLESER
inner join QUELLEN    on QUELLEN.ID_QUELLEN       = HOERBUCH.QUELLE
;

Man sieht, das ist letztendlich einfacher zusammenzubauen als ein komplizierter SQL-Befehl in deiner Anwendung. 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.:

Delphi-Quellcode:

Procedure TDatMod.SortierenHoerbuch(Spalte: Integer);
Const
  K = ';';
  SortText = ' Hörbücher sortiert nach "';

Var
  SortAus,
  SortOrd,
  SqlSort : String;

begin
  If GLD.URec.HB_SortOrd Then
  Begin
    SortOrd := '" aufwärts';
    SqlSort  := ':A';
  End Else
  Begin
    SortOrd := '" abwärts';
    SqlSort := ':D';
  End;

  Case Spalte Of
   0 : Begin
         Tab_V_Hoerbuch.IndexFieldNames := 'TITEL'      + SqlSort + K + 'AUTOR'     + SqlSort + K + 'VORLESER' + SqlSort + K +
                                           'SPRACHE'    + SqlSort + K + 'KATEGORIE' + SqlSort + K + 'HOERART'  + SqlSort + K;
         SortAus := 'Titel';
...

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