Einfaches Datenbankmodell

[Rollo62]

Zitat von TigerLilly:

Allgemein:
* Die Tabellen alle mit TBL_ beginnen zu lassen ist überflüssig.
* Ich bevorzuge es, die IDs (=PKs) mit dem Tabellennamen zu benennen. So wie du es bei Tbl_User gemacht hast (Tbl_USer -> UserID), aber bei den anderen nicht (Tbl_Konto -> ID)
* Die IDs einmal mit und einmal ohne _ zu bennen ist nicht gut. Adress_ID und UserID ist eine ziemliche Fehlerquelle.
* Ich würde nicht mit den Standarddatentypen arbeiten, sondern UDDT, also selbst definierte Typen, verwenden + allen Feldern, die gleichen Typ haben, diesen zuordnen. Also statt FLOAT bei Beträgen würde ich einen UDDT "Betrag" vom Typ Float zwischenschalten. Diesen ev. mit Default oder not null etc aufpeppen. Das macht es dann zB leichter alle Telefonnummern zu verlängern, weil du nur einmal den UDDT ändern musst.
* Mach dich über den Unterschied zwischen VARCHAR und NVARCHAR schlau.
* INT INTEGER DEC FLOAT ist ein ziemliches Typgemisch - siehe vorher UDDT.
* "Text" als Feldname ist unglücklich, da a) nichtssagend + b) oft ein reserviertes Wort.
* Tabellennamen sollten einheitlich entweder alle Einzahl oder alle Mehrzahl sein. Jetzt gibt es die Tbl_Firma, aber auch die Tbl_Adressen.

Solche Konventionen finde ich immer sehr gut, ich arbeite zwar nicht mit den komplexesten DBs aber hilfreich ist das immer.
Das kann ich Alles unterstreichen, und weiche davon nur in Sonderfällen ab (OK bei den Datentypen manchmal).

Zitat:

* Ich bevorzuge es, die IDs (=PKs) mit dem Tabellennamen zu benennen.

Ich benutze im Moment zwar möglichst konsequent ID, das sit aber eine gute Idee, werde ich mir mal ansehen.

Was ich als Konvention für mich festgestellt habe ist das bei den meisten Tabellen eine
möglichst gleiche Nomenklatur benutzen sein kann (nicht bei Allen Tabellen wohlgemerkt).
In der Art:

• ID(_xxxx) - als PK
• Name - Passt fasst immer, da muss ich nicht XxxxName schreiben, denn der Zusammenhang macht es klar
• Descr - eine Beschreibung zum Eintrag kann ich auch ziemlich oft dazunehmen
• 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

Rollo

[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

[TigerLilly]

Geschmäcker und so.

[Rollo62]

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

Ich wollte ja nur mögliche Auswege zeigen.