Firebird Embedded + AUTOINC

[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 von Uwe Raabe:

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 von Uwe Raabe:

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 von mkinzler:

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 von mkinzler:

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 von mkinzler:

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 von mkinzler:

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 von 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ö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.

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 von Bernhard Geyer:

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