Hallo zusammen,
Zwei Dinge bei denen ich mir nicht im klaren bin, ob es so gut ist wegen den Normalformen.
Folgendes.
Es gibt eine Tabelle "users" mit Spalten wie:
UserID, User, Email, Kostenstelle, Login,..
1, Klaus, kk@kk.de, 1234, klaus
2, Werner, ww@ww.de, 3456, werner
3, Gustav, gg@gg.de, 8899, gustav
....
Dann gibt es eine Tabelle "messages" mit Spalten
MessageID, UserID, SenderID, Message
1, 1, 2, "Hallo Klaus wie gehts"
2, 2, 1, "Hallo Werner, danke gut"
3, 3, 1, "Hallo Gustav, "
Ich speichere also die UserIDs von Tabelle "users" in den Spalten "UserID" und "SenderID" der Tabelle "messages".
Ist das vom Aufbau bzw. von der Normalform her gesehen ok so?
Wären dann die Spalten "UserID" und "SenderID" die "ForeignKeys" zur Tabelle "users"?
Wenn ich nun daraus mit einem Programm versuche ein Diagramm mit reverse Engineering zu machen, wird zwar die Relation "UserID"---> "UserID" erkannt, nicht jedoch "UserID"--->"SenderID".
Vermutlich deswegen weil die SPalte anders heisst?
Anderes Beispiel:
Es gibt die Tabelle "constraintselements"
---------------------------------------------------------------
ConElementID, Element
1, Blau
2, Rot
3, Gelb
4, Braun
Dann gibt es die Tabelle "constraints"
----------------------------------------------------------
ConID, ConElementID1, ConElementID2, GroupID
1, 1, 2, 3
2, 1, 4, 3
3, 3, 4, 1
Was ich hier nicht weiss. Es gibt die Beziehung zu "ConElementID" in den Spalten "ConElementID1" und "ConElementID2"
Ich habe mal gelesen dass man derartige Spaltennamen vermeiden soll.
Wäre es besser diese "constraints" Tabelle in zwei Tabellen aufzusplitten?
viele Grüße
hawk