Einfaches Datenbankmodell

[DeddyH]

Bei mir heißt der PK immer ID, FKs sind nach dem Muster <RefTable>ID benannt, also z.B.

Code:

 CREATE TABLE Address(
  ID INTEGER NOT NULL PRIMARY KEY,
  PersonID INTEGER,
  CONSTRAINT FK_Person
  FOREIGN KEY(PersonID) REFERENCES Person(ID)
)

Letztendlich ist es aber auch wurscht, wie man das handhabt, wichtiger ist in meinen Augen, dass man das Muster erkennen kann und dieses auch konsequent eingehalten wird.

[TigerLilly]

Zitat:

Name - Passt fasst immer, da muss ich nicht XxxxName schreiben, denn der Zusammenhang macht es klar

Ah - guter Punkt. Es sollte (bis auf wenige Ausnahmen) keine gleichbenannten Felder geben. Wenn du einen Join über mehrere Tabellen hast + da kommt 4x "Stadt" vor, hilft dir der Zusammenhang nicht viel.

Zitat:

[*]ChgFirst - Oft ist es sinnvoll den Ersteller des Records zu protokollieren[*]ChgLast - sowie Wer hat den Record zuletzt geändert[*]ChgTime - und wann war das

Ein konzeptionelles Datenmodell versteht "Vererbung" + da kann man sowas gut abbilden.

Ich habe in meinen Tabellen auch noch ein Feld "Serial", das bei Änderungen hochgezählt wird. Dann kann die WHERE Clausel für das Update "where PK=... and Serial=..." lauten + darauf kann man einen knackigen Index setzen.

Zitat:

Bei mir heißt der PK immer ID, FKs sind nach dem Muster <RefTable>ID benannt, also z.B.

Warum nicht gleich <table>ID? Siehe oben - ein Join über 4 Tabellen + du hast 4x ID.
Außerdem: Gleiche Bezeichnung == gleicher Inhalt. (Bis auf wenige Ausnahmen, meistens so Verwaltungsfelder.)

[DeddyH]

Weil <Table>ID bei mir ein Zeichen für einen Fremdschlüssel ist, dann kommt man nicht durcheinander.

[mkinzler]

Zitat:

Warum nicht gleich <table>ID? Siehe oben - ein Join über 4 Tabellen + du hast 4x ID.

Ich nenne PK auch immer nur ID. In Deinem Beispiel könnte man bei der Abfrage Aliase setzen oder die FK-Felder der Detailtabellen.

[Rollo62]

[QUOTE=TigerLilly;1406004]

Zitat:

Wenn du einen Join über mehrere Tabellen hast + da kommt 4x "Stadt" vor, hilft dir der Zusammenhang nicht viel.

Ja ich gebe zu das ich nicht mit superkomplexen DB-Strukturen arbeite (bis auf ein DATEV-Projekt), aber manches lässt sich auch dann besser lesbar darstellen:

Code:

select mi.Personalnummer as MitNr, 
       mi.Name as MitName, // Alias
       mi.Vorname, 
       dw.ID, dw.Kennzeichen, dw.Fahrzeugtyp_ID as Typ
  from Mitarbeiter mi
       join Dienstwagen dw 
         on mi.ID = dw.Mitarbeiter_ID 
 where dw.Fahrzeugtyp_ID in ( SELECT ft.ID
                                from Fahrzeugtyp ft
                                     join Fahrzeughersteller Fzg  // Alias
                                       on ft.Hersteller_ID = fh.ID
                               where Fzg.Name = 'Mercedes-Benz');  // Alias.Name

Ist jetzt vielleicht nicht das beste Beispiel :stupid:

[TigerLilly]

:thumb: Geschmäcker und so. :-D

[Rollo62]

Nein nein, du hast ja Recht.
Bei 5+ Tabellen im JOIN wird es wohl unübersichtlicher.
Dann bin ich ganz bei dir :thumb:

Ich wollte ja nur mögliche Auswege zeigen.