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.
Zitat
Baum-Darstellung
