Hi zusammen

Zur Zeit arbeite ich an einer SQLite-DB für meinen PDFOfficer. Zuerst hier mal mein DB-Modell, mit MySQL Workbench erstellt und anschliessend nach SQLite exportiert:
PDFOfficerDataModell 3.jpg
Parallel dazu bin ich dabei, mir mit Google Translate Passagen aus dem SQLite-Handbuch zu übersetzen, aktuell zum Thema CreateTable und gewissen Constraints. Aus den übersetzten Texten stelle ich mir Word-Dokumente als Lern- und Nachschlagequellen zusammen.
Dabei hat sich für mich nun eine Unklarheit ergeben. Aus meiner Google-Übersetzung:

Zitat:

Der übergeordnete Schlüssel einer Fremdschlüsseleinschränkung darf die Zeilen-ID nicht verwenden. Der übergeordnete Schlüssel darf nur benannte Spalten verwenden.

Der Originaltext:

Zitat:

The parent key of a foreign key constraint is not allowed to use the rowid. The parent key must used named columns only.

Unter dem 'übergeordneten Schlüssel' verstehe ich in jedem Fall den Primärschlüssel der Elterntabelle, und nach meinem Verständnis ist der in der Elterntabelle gleichzeitig die ZeilenID. Der zweite Satz ist automatisch erfüllt: Ups, Kommmando zurück - ich bins, der das automatisch macht. Ich hab das soeben mal durchgespielt. Nach benennen des ersten Feldes wird Integer als Datentyp vorgeschlagen, und bei verlassen dieses Feldes werden die Haken bei Primarykey und NotNull gesetzt. Was da passiert, wenn ich einen andern Datentyp wähle, habe ich noch nie probiert...
Nun ja, dadurch, dass ich das PK-Feld anlege, habe ich eine benannte Spalte.

Meine Verständnisfrage ist also eigentlich lediglich: Was soll das mit der Zeilen-Id, die nicht verwendet werden darf? Zumal ich ja gerade die bei einem Insert über mehrere Tabellen abfrage? (LastRowId)

Gruss
Delbor

Sqlite hat per default ein Feld rowid (Integer) als primären index
dieser darf nicht als fremdschlüssel verwendet werden.

Hat Deine Tabelle einen integrierten primary key sind diese intern identisch.

Die Aussage

Zitat:

The parent key of a foreign key constraint is not allowed to use the rowid. The parent key must used named columns only.

bezieht sich nur darauf. Wenn Du eine PK mit Namen hast is alles gut

Hi Fritzew

Danke für deine prompte Antwort!

Gruss
Delbor

Wozu hat eigentlich SQLite diese automatische ID Spalte?
Für Tabellen ohne definierten PK?
Aber wer erstellt denn Tabellen ohne PK?

Hi Turbo Magic

Ich kann noch nicht behaupten, alles verstanden zu haben. Nur soviel: Wenn das deklarierte PK-Feld vom Typ INTEGER, aber kein Int oder Bigint ist, ist es ein Alias für die RowId. Für den Fall, dass du ebenso wie ich mit dem Englisch mehr oder wenigger auf Kriegsfuss stehst, findest du im Anhang mal ein gezipptes Worddokument mit meinen bisherigen Übersetzungen.
SQLite - Tabelle erstellen.zip

Gruss
Delbor

Ganz allgemein ist es nicht empfehlenswert, db spezifische Mechanismen bei der Modellierung zu verwenden. Wenn SQLite das mit der ROWID freiwillig in Form eines Alias macht, soll es so sein, aber selbst macht man es halt nicht, egal welche DB.
Eigentlich hat jede DB einen ureigenen Mechanismus, um eine Zeile selber zu adressieren und die meisten Systeme dokumentieren den auch, rowid bspw. gibt es glaub ich in verschiedenen DB.

Und nochwas:
Was auch immer man mit einem grafischen Tool macht, es ist interessant, die Create Anweisung selber zu schreiben und natürlich auch die gewünschten Constraints (PK, FK, usw..)
Die spielt man ein und verwendet dann ein Tool, um die "Ergebnisse" wieder auszulesen (DML). Das ist manchmal sehr erhellend. Die Differenz zwischen beiden Scripten spiegelt z.B. die ganzen Defaults, die das System "freiwillig" annimmt.

Will sagen, entscheidend und richtig und wichtig ist nicht unbedingt, was (irgend-)ein grafisches Tool macht oder in "vorauseilendem Gehorsam" einträgt/ausblendet, sondern die Defaults und Vorgaben der Engine. Die sollten natürlich gemäß Doku erfolgen.
Defaults sind am Ende dann auch nur ein Komfortangebot und können durch explizite Angaben überschrieben werden (beim CREATE oder per ALTER)

Am Ende kann man natürlich gerne Tools für den Entwurf einsetzten. Den Feinschliff macht man vielleicht besser per Hand und inkludiert Defaults in das Script.
Damit ist ein Script basiertes Datenmodell dann auch stabil bei Versionswechsel der DB, es ist besser verständlich und versionierbar.