Ludger: Frage zum DB-Design

Beitrag lesen

Hi,

also sowas:

es ist nicht nötig, in den Spaltennamen den Namen der Tabelle zu wiederholen. Enthalten die "_GUID"-Spalten die Datensatz-IDs?

Die GUIDs sind fuer mich globale ("Netzwerkkarten-ID abhaengige") IDs (oft Hexwerte), waehrend die IDs fuer mich benutzerfreundliche Datentabellen-eindeutige IDs sind, also oft Integers.
Die Namenskonvention hat sich so ergeben, damit man DB-eindeutige Datenfeldnamen hat, was sich als guenstig erwiesen hat fuer die Kommunikation und fuer die Intuitivitaet komplexer Abfragen bspw..

Vertraege_Vertragsgegenstaende_Relationships (DBTabelle)
Vertraege_Vertragsgegenstaende_Relationship_GUID (Datenfeld)

Wenn ja, wäre diese Spalte beispielsweise unnötig, weil sie sich aus Vertrag_GUID und Vertragsgegenstand_GUID ergibt.

Wir haben da bestimmte Vorgaben die ID-Gebung betreffend.
Du schlaegst aber anscheinend einen kombinierten Primaerschluessel vor, der dann natuerlicherweise eine doppelte Zuordnung eines Gegenstands zu einem Vertrag unterbinden wuerde. Aha, gute Idee, leider bei uns nicht zugelassen. Haette ich dazuschreiben sollen, aber ich hatte Deinen Loesungsvorschlag nicht antizipieren koennen.   :-(

Vertraege_Vertragsgegenstaende_Relationship_Timestamp (Datenfeld)

Ob dies nötig ist, kann ich nicht beurteilen. Ist es eine Art Eintrags- oder Änderungs-Zeitpunkt?

Vorgaben. (Historisierung, Stndardisierung und so)

Als dritte Spalte könnte sich ggf. die Position anbieten, was natürlich nicht ganz unproblematisch ist;

Meinst Du die Position eines Vertragsgegenstandes innerhalb eines Vertrags (Das ist nicht angefordert) oder etwas anderes?

Ja, genau das. Schön, wenn Du es weglassen kannst :-)

Wirklich schoen.   :-)
Allerdings werde ich da sofort neugierig und frage mich, wie man so was idealerweise macht. (Datentyp Integer und die Regel, dass doppelte Werte unzulaessig (CHECK-Constraint)?)

Gruss,
Ludger