Firebird Embedded + AUTOINC

[himitsu]

Moin moin,

gibt es in Firebird wirklich keine AUTOINC-Felder.


Hab's jetzt erstmal nach dieser Anleitung hinbekommen.
http://www.firebirdfaq.org/faq29/

Aber ich finde es dennoch recht umständlich.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1286866)

gibt es in Firebird wirklich keine AUTOINC-Felder.

Ist so!

[Perlsau]

Zitat:

Zitat von himitsu (Beitrag 1286866)

Aber ich finde es dennoch recht umständlich.

Ist nur scheinbar umständlich. Wenn du den IbExpert* einsetzt, kannst du beim Erstellen einer Tabelle selbstverständlich auf einfachste Weise ein AutoInc-Feld anlegen, wie man in der Grafik unten deutlich sehen kann. Dazu mußt du nur die CheckBox mit dem Titel AI ankreuzen, und es erscheint der Dialog für das Autoinkrementfeld. Dort wählst du Procedure, Generator und Trigger automatisch erzeugen, und fertig. In anderen DBMS ist das im Grunde nicht viel anders geregelt, nur wird dir dort vielleicht verborgen, was im Einzelnen genau vonstatten geht, wenn du einen neuen Record anlegst, dessen PK ein AutoInc-Feld ist. Auch in Access wird intern ein Trigger ausgelöst, der eine vorbereitete Procedure ausführt, die den Generator für eine neue PK-Id anwirft. Ich empfinde das bei Firebird als sehr übersichtlich und leicht verständlich und den Einsatz von IbExpert dabei als äußerst hilfreich.

* Für die Personalversion mußt du dich dort registrieren, kostet aber nichts. Und jeden Monat einmal wird deine Registrierung beim Start von IbExpert abgefragt, du mußt dann deine Registrierungsnummer eingeben.

[mkinzler]

Vorteil ist aber, dass Du den Vorgang steuern kannst. Z.B. andere Schrittweite oder gemiensamen Generator für mehrere Tabellen usw.

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1286866)

Aber ich finde es dennoch recht umständlich.

Kann ich verstehen, vor allem wenn man es von anderen SQL-Dialekten anders gewohnt ist .
Aber da weiß man woher es kommt, und die Werte fallen nicht vom Himmel oder müßen von einem, von zig Generatoren abgeholt werden.

Gruß
K-H

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1286881)

Vorteil ist aber, dass Du den Vorgang steuern kannst. Z.B. andere Schrittweite oder gemiensamen Generator für mehrere Tabellen usw.

Dies widerspricht aber der Maxime, seine Surrogatschlüssel nichtsprechend zu halten. Insofern ist das nicht unbedingt ein Vorteil.

Zitat:

Zitat von Perlsau (Beitrag 1286870)

...Wenn du den IbExpert* einsetzt, kannst du beim Erstellen einer Tabelle selbstverständlich auf einfachste Weise ein AutoInc-Feld anlegen...

Soweit ich mich erinnere ist die Pflege der Eigenschaft nicht mehr so einfach.

Generatoren sind allgemeingültiger, und vielleicht dachte jemand, das sei schlau.

Unpraktisch ist es in jedem Fall. Nur weil IBEXPERT das auch so sieht und deshalb so tut, als ob es eine AutoInc-Eigenschaft eines Datentypen gibt, heißt das ja nicht, das diese Generatorenvertriggerung sinnvoll ist, eher das Gegenteil.

Aber letztendlich ist es ein Feature, mit dem man leben kann.

[mkinzler]

Zitat:

Dies widerspricht aber der Maxime, seine Surrogatschlüssel nichtsprechend zu halten. Insofern ist das nicht unbedingt ein Vorteil.

Und mit anderer Schrittweite ist er nun abhängig von den Werten der Tabelle? Oder wird verhindert das Wete in der Tabelle nicht mehr geändert werden könnenn, wenn jemand möchte, dass der PK über mehrere Tabellen eindeutig ist?

Zitat:

Generatoren sind allgemeingültiger, und vielleicht dachte jemand, das sei schlau.

Generatoren oder Sequenzen gibt es auch in anderen DBMS und sind idZw. auch Teil des SQL-Standards.

Dann nimm halt ein "intelligentes" Datenbanksystem mit autoinc wie zB. Paradox oder access und mach einen großen Bogen um die "unpraktischen" Frickelsystem wie FireBird, Oracle und Co.

[p80286]

Zitat:

Zitat von mkinzler (Beitrag 1286889)

Dann nimm halt ein "intelligentes" Datenbanksystem mit autoinc wie zB. Paradox oder access und mach einen großen Bogen um die "unpraktischen" Frickelsystem wie FireBird, Oracle und Co.

Frickelsysteme ist Guuut.

Aber im Ernst, wenn man die DB als bessere Datenhalde nutzt, mehr braucht man manchmal nicht, dann ist man mit "intelligenten" Systemen ganz gut bedient.

Gruß
K-H

[mkinzler]

Ich würde auch dann keines der von mir genannten Systeme verwenden. Aber das ist meine persönliche Meinung.

[Perlsau]

Eben :thumb: Weshalb sollte man alte, unmoderne und unflexible Software einsetzen, wenn man ebenso auch neue, moderne und flexible Software haben kann? Wie so oft kann ich mich des Eindrucks nicht erwehren, daß auch in diesem Bereich mehr aus Gewohnheit für das Alte plädiert wird denn aus sachlicher Überzeugung.

[Uwe Raabe]

MS SQL Server hat übrigens auch AutoInc-Felder, obwohl ich den jetzt nicht unbedingt in einer Linie mit Paradox oder Access aufstellen möchte.

Der Vorteil bei MSSQL gegenüber Firebird/Interbase ist aber, daß FireDAC dort den gerade erzeugten AutoInc-Wert auslesen und an die Anwendung zurückgeben kann. Bei Firebird/Interbase funktioniert das leider nicht und man muss dort andere Maßnahmen ergreifen. Im Endeffekt läuft es sogar darauf hinaus, daß FireDAC zwar auch den Generator benutzt, diesen Wert aber beim Insert übergibt und damit den Trigger außer Kraft setzt. So ganz ohne Trigger geht es aber auch nicht, wenn auch aus anderen Quellen Daten hinzugefügt werden sollen.

Ein simples AutoInc-Feld in MSSQL (dort heißt es übrigens Identity) hat kürzlich bei einem Port auf Interbase schon einen gewissen Aufwand verursacht und (das in fast jeder Tabelle). Damit ging dann auch die eigentlich einfache Umschaltung des Zieldatenbanksystems in Rauch auf bzw. wurde deutlich komplexer als veranschlagt. Das kann ich mir auch etwas developer friendly vorstellen.

Ach ja, MSSQL gibt es mittlerweile auch kostenfrei als Embedded System.

[mkinzler]

Microsoft, Microsoft über alles und nur hirnies verwenden OS!

Nur weil FireDAC mit dem Mechanismus von interbase/firebird nicht zurecht kommt, soll nun jeder MSSQL nehmen? FB kennt übrigens RETURNING, mit Hilfe man sich den Wert zurückgeben lassen kann.
Der explizite autoinc per Direktive kommt übrigens bald bei FireBird.

[Bernhard Geyer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1286919)

Der Vorteil bei MSSQL gegenüber Firebird/Interbase ist aber, daß FireDAC dort den gerade erzeugten AutoInc-Wert auslesen und an die Anwendung zurückgeben kann.

Bei aktiver Replikation muss man aber aufpassen. Die gerne Verwendete Funktion @@IDENTITY liefert bei aktiver Replikation nicht das was man erwarten würde.

Zitat:

Zitat von Uwe Raabe (Beitrag 1286919)

Ach ja, MSSQL gibt es mittlerweile auch kostenfrei als Embedded System.

Dann sollte aber die DB nicht zu groß werden. Und nicht jeder kann ein .NET-Umfeld vorraussetzen.


Aber wieso werden immer Autoincfelder verwendet? Wir verwenden hier lieber GUIDs um diverse Nachteile von AutoInc-Felder zu umgehen. Und diese Zahlenwerte sind auch nicht lesbarer als die GUIDs

[Uwe Raabe]

Zitat:

Zitat von mkinzler (Beitrag 1286920)

Microsoft, Microsoft über alles und nur hirnies verwenden OS!

Du interpretierst da offenbar irgendetwas in meinen Post hinein, das da gar nicht drin steht. Oder darf man hier jetzt neuerdings nur die Vorzüge eines Systems aufzeigen, wenn es Open Source und nicht von Microsoft ist?

Zitat:

Zitat von mkinzler (Beitrag 1286920)

Nur weil FireDAC mit dem Mechanismus von interbase/firebird nicht zurecht kommt, soll nun jeder MSSQL nehmen?

Es kommt ja zurecht damit - nur eben anders. Ich sagte ja auch nicht, daß es damit nicht geht, sondern daß es etwas aufwändiger ist.

Abgesehen davon liegt die Wahl der Datenbank ja auch nicht immer in der Hand des Entwicklers.

Zitat:

Zitat von mkinzler (Beitrag 1286920)

FB kennt übrigens RETURNING, mit Hilfe man sich den Wert zurückgeben lassen kann.
Der explizite autoinc per Direktive kommt übrigens bald bei FireBird.

Na, dann ist ja alles gut.

[Daniel]

Zitat:

Zitat von mkinzler (Beitrag 1286920)

Nur weil FireDAC mit dem Mechanismus von interbase/firebird nicht zurecht kommt, soll nun jeder MSSQL nehmen?

:?
Ich fürchte, da hast Du tatsächlich etwas in den falschen Hals bekommen. Aktuell tauschen wir uns doch lediglich über die Herangehensweisen diverser Systeme aus.

Am Rande: Gerade FireDAC kommt mit dem Systems bestens zurecht, ich kann in der Komponente einstellen, wann ich den Wert aus dem Trigger generieren lassen möchte - wahlweise wenn ich clientseitig ein neues Record anlege oder erst später beim Post. Je nach Bedarf sind mir in der freien Wildbahn schon beide Varianten vor die Flinte gelaufen.

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1286889)

Zitat:

Dies widerspricht aber der Maxime, seine Surrogatschlüssel nichtsprechend zu halten. Insofern ist das nicht unbedingt ein Vorteil.

Und mit anderer Schrittweite ist er nun abhängig von den Werten der Tabelle? Oder wird verhindert das Wete in der Tabelle nicht mehr geändert werden können, wenn jemand möchte, dass der PK über mehrere Tabellen eindeutig ist?

Das ist dann i.A. kein gutes Design, aber darum geht es nicht. Für den Regelfall, nämlich einen PK in einer Tabelle, kann man AutoInc einführen. Und Generatoren obendrauf, z.B. für die Exoten, die eine gemeinsame Nummer für unterschiedliche Tabellen haben wollen.

Zitat:

Zitat:

Generatoren sind allgemeingültiger, und vielleicht dachte jemand, das sei schlau.

Generatoren oder Sequenzen gibt es auch in anderen DBMS und sind idZw. auch Teil des SQL-Standards.

Yo. Jemand dachte halt, das sei schlau.

Zitat:

Dann nimm halt ein "intelligentes" Datenbanksystem mit autoinc wie zB. Paradox oder access und mach einen großen Bogen um die "unpraktischen" Frickelsystem wie FireBird, Oracle und Co.

Lass das mal mit dem Hyperventilieren. Nur weil man Generatoren ohne Autoinc-Felder nicht als Nonplusultra erachtet, heißt das ja nicht, das man das RDBMS für ein Frickelsystem hält. Keine Ahnung, wie Du darauf kommst. :roll:

Ideal wäre es, wenn in FB z.B. noch ein Attribut (oder ein Datentyp) 'AUTOINC' hinzukommt. Dann wäre Ruhe. Natürlich würden viele schreien 'Das braucht man nicht, das macht mit mit nem Generator und nem Trigger', aber For-Schleifen braucht man auch nicht, und es gibt sie trotzdem. Denn sie sind praktisch.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1286925)

Aber wieso werden immer Autoincfelder verwendet? Wir verwenden hier lieber GUIDs um diverse Nachteile von AutoInc-Felder zu umgehen. Und diese Zahlenwerte sind auch nicht lesbarer als die GUIDs

Ich meine, die Speicherperformance bei GUID-PK (Clustered Index) ist schlechter als bei einem Indentity-Wert. Aber als eindeutige ID über Tabellen- und Servergrenzen hinweg ist es schon echt praktisch.

BTW: Zum Thema Lesbarkeit von GUID:
"Ey, Bernhard, welcher Record hat nochmal das Problem? Ich wollte kurz mal da rein schauen"
A: "ID 12 45 678"
B: "C87FC... ach, ich schicks Dir per Skype"

[tsteinmaurer]

Zitat:

Ideal wäre es, wenn in FB z.B. noch ein Attribut (oder ein Datentyp) 'AUTOINC' hinzukommt

Firebird 3 wird hierfür etwas anbieten. Beispiel:

Code:

create table t2 (
t2_id bigint generated by default as identity
, i integer
, constraint pk_t2 primary key (t2_id)
);

LG

[himitsu]

Zitat:

Frickelsystem

Das ist gut.

Irgendwie ignoriert das Ding sogar ein Order-By und macht einfach nicht.
Weder sortieren, noch eine Fehlermeldung.

Ist doch nur ein billiges VARCHAR-Feld und mit INTEGER ging es auch nicht. :wall:
Und am schrottigen Delphi-DBGrid kann es nicht liegen, da dieses weder Sortierung noch Filterung kennt. (ist auch wirklich im Query so unsortiert)



Da will man mal privat bissl rumspielen und dann funktioniert einfach nichts.

• DBImage versteht nur Bitmaps
• Die Sortierung funktioniert nicht
• und über Grids und schrottiges LiveBinding an Objectliste will ich nicht mehr nachdenken, drum wollte ich es jetzt mit einer "richtigen" DB versuchen

Hatte mit MySQL-Embedded angefangen, dann fielen mir wieder die Diskussionen vonwegen Lizenzen an und ich probierte mal das "coole" Firebird aus, was doch immer wieder gelobt wird.
Aber vielleicht liegt es ja auch am FireDAC, aber mit PgDAC hatte eigentlich nicht solche Probleme (nur hab ich diese DB hier nicht und das war auch noch nicht von Emba)

[Hansa]

Lass mal die ganze Delphi-Seite vorerst weg. Lege in IBExpert Tabelle an, einen Generator und einen BI-Trigger für die ID. Dann füge ein paar Datensätze ein und guck, ob die ID korrekt hochgezählt wird (also automatisch, nicht von Hand !!)

[Daniel]

@Himi:
Wie sortierst Du denn? FireBird kann das ganz hervorragend, sowohl bei Zahlen als auch bei Strings - auch unter Berücksichtigung von Ländercodes. Gleiches gilt für FireDAC.

[DeddyH]

Wenn der Stürmer nicht trifft, ist der Ball Schuld :roll:

[himitsu]

Eigentlich ganz normal. :gruebel:

SQL-Code:

SELECT *
FROM tabelle
ORDER BY spalte1, spalte2

Und probehalber auch

SQL-Code:

...
ORDER BY spalte1

...
ORDER BY spalte1 DESC

Als Ergebnis kommt aber immer die Erstellungsreihenfolge der Datensätze in der Tabelle raus.

Einfach mal alles Wichtige aus der DFM.
Im Code steht praktisch nur noch das Open.
Und in ".\Firebird Embeded" liegt der gesamte Inhalt der ZIP. (die Verzeichnisse sind aktuell aber absolute Pfade, damit ich die Connection auch in der IDE auf bekomm)

Code:

object FDPhysFBDriverLink: TFDPhysFBDriverLink
  DriverID = 'FirebirdEmbedded'
  VendorLib = '.\Firebird Embeded\fbembed.dll'
  Embedded = True
  Left = 64
  Top = 72
end
object FDConnection: TFDConnection
  Params.Strings = (
    'Database=.\database.ib'
    'Password=masterkey'
    'User_Name=sysdba'
    'CharacterSet=UTF8'
    'OpenMode=OpenOrCreate'
    'DriverID=FirebirdEmbedded')
  Connected = True
  LoginPrompt = False
  Left = 168
  Top = 72
end

object FDGUIxWaitCursor: TFDGUIxWaitCursor
  Provider = 'Forms'
  Left = 272
  Top = 72
end
object FDStanStorageBinLink: TFDStanStorageBinLink
  Left = 376
  Top = 72
end

object DBGridSeries: TDBGrid
  Left = 8
  Top = 483
  Width = 257
  Height = 118
  Anchors = [akLeft, akBottom]
  DataSource = DataSourceSeries
  Options = [dgEditing, dgTitles, dgIndicator, dgColumnResize, dgColLines, dgRowLines, dgTabs, dgAlwaysShowSelection, dgConfirmDelete, dgTitleClick, dgTitleHotTrack]
  TabOrder = 2
  TitleFont.Charset = DEFAULT_CHARSET
  TitleFont.Color = clWindowText
  TitleFont.Height = -11
  TitleFont.Name = 'Tahoma'
  TitleFont.Style = []
end

object FDQuerySeries: TFDQuery
  AfterScroll = FDQueryCountryAfterScroll
  FilterOptions = [foCaseInsensitive]
  IndexFieldNames = 'series_id'
  Connection = FDConnection
  UpdateOptions.AssignedValues = [uvGeneratorName]
  UpdateOptions.GeneratorName = 'euro_series_gen_id'
  UpdateOptions.UpdateTableName = 'euro_series'
  UpdateOptions.KeyFields = 'series_id'
  UpdateOptions.AutoIncFields = 'series_id'
  SQL.Strings = (
    'SELECT *'
    'FROM euro_series'
    'ORDER BY series_name, series_id')
  Left = 168
  Top = 128
  object FDQuerySeries_series_id: TIntegerField
    DisplayLabel = 'ID'
    DisplayWidth = 7
    FieldName = 'series_id'
    Origin = 'series_id'
    ReadOnly = True
    Required = True
  end

  ...

end;
object DataSourceSeries: TDataSource
  DataSet = FDQuerySeries
  Left = 168
  Top = 184
end

object DBNavigatorSeries: TDBNavigator
  Left = 115
  Top = 460
  Width = 150
  Height = 22
  DataSource = DataSourceSeries
  VisibleButtons = [nbInsert, nbDelete, nbEdit, nbPost, nbCancel, nbRefresh]
  Anchors = [akLeft, akBottom]
  TabOrder = 3
end

[jobo]

Würd ich auch mal für ein Gerücht halten, dass FB nicht sortieren kann. Vielleicht ein Charset/Collate Problem?

Noch ein Gedanke zu Sequenzen:
Eine tabellenübergreifende ID per Sequenz ergibt immer leere Mengen, bei falschen Joins. Im Gegensatz zu fortlaufenden ID je Tabelle, falsche Joins spucken dann brav Schrott aus.
Zugegeben, Ursache ist ein falsches Select, aber ich finde den Effekt ganz nett.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1286954)

Als Ergebnis kommt aber immer die Erstellungsreihenfolge der Datensätze in der Tabelle raus.

Na, das sagst du doch der Query aber auch:

Zitat:

IndexFieldNames = 'series_id'

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1286956)

Na, das sagst du doch der Query aber auch:

Zitat:

IndexFieldNames = 'series_id'

:wall: und dann stammt dieser Eintrag noch aus den Versuchen mit MySQL.

Danke.

Sortiert das eigentlich auch neue Datensätze?
(die werden ja erst nach dem Refresh richtig einsortiert)
Werd es dann gleich ausprobieren ... falls ich's richtig mach und es nicht nur zufällig irgendwas macht, wo ich dann denk es ist immer so. :stupid:

Zitat:

[FireDAC][Phys][FB]validation error for column "COINS_SERIES", value "*** null ***"

Jetzt muß ich nur noch die NULL finden, welche seit 'ner Stunde aufgetaucht ist. (vorher ging es)
Der Debugger meint da steht was drin (eine "1"). Diese wurde/wird im AfterInsert gefüllt und ist beim Post auch immernoch drin.

Und wie man FireDAC dazu bekommt die drangejointen Felder und das AutoInc beim Post richtig zu laden und nicht erst beim nächsten manuellen Refresh.

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1286928)

Abgesehen davon liegt die Wahl der Datenbank ja auch nicht immer in der Hand des Entwicklers.

So ist das!
Und es schadet auch nicht, immer mal wieder auf Unzulänglichkeiten hinzuweisen, wenn welche auffallen. U.U. sitzt die Unzulängichkeit ja vor der Tastatur, und man kann noch etwas dazu lernen.

Aber deswegen müssen wir uns doch nicht die Schädel einschlagen? Oder?


Gruß
K-H

[Perlsau]

Zitat:

Zitat von himitsu (Beitrag 1286959)

Sortiert das eigentlich auch neue Datensätze?

Aber sicher doch. Wenn ich einen neuen Datensatz einfüge, steht der immer gleich an der richtigen Stelle, wenn in der Query-Komponente IndexFieldNames mit einem oder mehreren gültigen Feldnamen gesetzt ist. Das ist doch Sinn und Zweck dieses Propertys, z.B.:

FireDac: Mit IndexFieldNames erstellen Sie Ad-hoc-Sortierreihenfolgen.

Oder anders ausgedrückt: Bislang ist es mir noch niemals untergekommen, daß eine via IndexFieldNames sortierte Datenmenge nach dem Einfügen oder Ändern eines Datensatzes nicht mehr korrekt sortiert war, und zwar bei allen mir bekannten Datenbank-Komponenten (FireDac, FibPlus, IbDac, dbGo, Zeos usw.). Einzig mit der BDE hab ich keinerlei Erfahrung vorzuweisen, aber die sollte man ja sowieso nicht mehr einsetzen.

[himitsu]

Hatte bisher nur im Grid sortiert (was richtige Grids ja können) oder halt über das SELECT und die Sortierung vom Select wird ist nach dem Laden nicht mehr existent.
Neue Zeilen rutschten beim ORDER-BY da rein, wo der Cursor grade stand (Insert) oder ans Ende (Append).

[himitsu]

Soooo, ich glaub nun geht erstmal alles wieder. :firejump:

Hätte nicht gedachte, daß für solche "Kleinigkeiten" so viel Zeit drauf geht.

Zuletzt gab es nur bei dem Query probleme, mit JOINs drin.
Anfangs ging es und dann plötzlich nicht mehr, obwohl ich mich nicht erinnern kann da was Schlimmes geändert zu haben.

Waren beim Insert Fehler wie Folgendes, obwohl das Feld nachweislich gefüllt war.
[FireDAC][Phys][FB]validation error for column "COINS_SERIES", value "*** null ***"
Oder beim Löschen "Feld xxxx nicht gefunden", was auch klar war, denn das kam auch aus einem JOIN.

Viel rumprobiert und ich glaub FireDAC ignoriert die ProviderFlags, mit welchen es (vor)zuletzt versuchte.
Nun ja, aus "SELECT *, xxx, yyy" statt "SELECT xxx, yyy, *" versucht und nun geht es und grade beim Schreiben fällt mir was auf. :wall:
Das Feld "NULL" war bestimmt zwei mal drin, wegen dem * (anfangs war das bestimmt noch tabelle.*)
[edit] Nee, es war doch "SELECT xxx, yyy, tabelle.*" und jetzt mit "SELECT tabelle.*, xxx, yyy" geht es und außerdem hab ich die Reihenfolge der Felder in der Query-Komponente umgedreht, so wie es Jetzt im Query steht.
[edit2] Letzteres hat keinen Einfluß.

[Perlsau]

Bequemer und eleganter find ich's, mit Views zu arbeiten: Du legst deine Joins praktisch schon in der DB an und kannst dann darin nach Herzenslust blättern und sortieren.

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

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

Zitat von Hansa (Beitrag 1286990)

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:

Zitat von Perlsau (Beitrag 1287002)

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

Delphi-Quellcode:

CREATE VIEW ... AS

weglassen und schon hat man das selbe SELECT-Statement, welches man direkt im Programm verwenden kann.

Zitat:

Zitat von Perlsau (Beitrag 1287002)

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

SQL-Code:

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:

Zitat von himitsu (Beitrag 1287014)

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:

Zitat von himitsu (Beitrag 1287014)

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

Will sagen: Ich verstehe deinen Einwand nicht wirklich :?:

Zitat:

Zitat von p80286 (Beitrag 1287029)

Äh Entschuldigung *hust*

Hier hast du ein Fishermen's extra stark :stupid:

Zitat:

Zitat von p80286 (Beitrag 1287029)

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

SQL-Code:

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

SQL-Code:

select ... from V_OpenInvoices

bekommt man was man will, da braucht's nicht bei jedem Aufruf wieder diese ToDate(to_char(to_date....)) frickelei ...". :thumb:

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

Zitat von mikhal (Beitrag 1287051)

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.