Der Foreign Key eines Datensatzes der Tabelle „a“ verweist auf einen Primary-Key eines Datensatzes in Tabelle „b“ und verbindet so beide miteinander.
Heißt das, Tabelle „b“ ist die Mastertabelle???
Wenn jetzt Daten in Tabelle b eingegeben werden, wie wird dann gleichzeitig ein dazugehöriger Datensatz in Tabelle a erzeugt?
Geht das überhaupt?
Oder muß anschließend (manuell) ein Datensatz in Tabelle a erzeugt werden der DANN den Key-Wert des grade erzeugten Satzes aus b erhält?
Der Foreign Key eines Datensatzes der Tabelle „a“ verweist auf
einen Primary-Key eines Datensatzes in Tabelle „b“ und
verbindet so beide miteinander.
Heißt das, Tabelle „b“ ist die Mastertabelle???
im SQL gibt es den Begriff Master nicht. a ist die referierte Tabelle, manchmal auch als parent table bezeichnet.
Wenn jetzt Daten in Tabelle b eingegeben werden, wie wird dann
gleichzeitig ein dazugehöriger Datensatz in Tabelle a erzeugt?
Gar nicht.
Oder muß anschließend (manuell) ein Datensatz in Tabelle a
erzeugt werden der DANN den Key-Wert des grade erzeugten
Satzes aus b erhält?
Andersrum: Erst muss der Key in a vorhanden sein, dann kann von b aus ein Bezug auf a hergestellt werden.
In Dialogen können natürlich beliebige Tricks versteckt werden, so zB das heimliche Anlegen eines Satzes in a und das anschließende Einrichten von b sowie das Aufbauen der Verknüpfung. Ist aber nicht empfehlenswert.
Hallo,
ein CONSTRAINT wie der PRIMARY KEY oder der FOREIGN KEY, der CHECK und der UNIQUE definieren Einschränkungen.
Ein FOREIGN KEY schränkt die erlaubten Werte auf die Werte ein, die bereits in der anderen Tabelle stehen.
Automatisch geht da nichts. Wie denn auch. Die DB kann schließlich nicht ahnen, welche Werte du eingeben willst.
Gruß
Peter
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Der Foreign Key eines Datensatzes der Tabelle „a“ verweist auf
einen Primary-Key eines Datensatzes in Tabelle „b“ und
verbindet so beide miteinander.
Andersrum: Erst muss der Key in a vorhanden sein, dann kann
von b aus ein Bezug auf a hergestellt werden.
nicht richtig. Erst muss ich doch den Satz haben, auf den der Foreign Key zeigen soll, also in diesem Fall: erst b, dann a. Hast du das falsch gelesen oder bin ich unterkoffeiniert?
Und zum eigentlichen Thema: Wann du welchen Datensatz in die Tabellen schreibst, sollte dir die Geschäftslogik für deine Applikation vorgeben. Aber (wenn man von solchen Sachen wie vorübergehendem Ausschalten der referentiellen Integrität absieht) erst muss der „Parent“ da sein, bevor irgendwelche „Children“ eingefügt werden können. Beispiel: Erst Auftragskopf, dann Auftragsposition etc.
und danke für die Antworten.
Haben mir weitergeholfen - glaube ich :o)
D.h., ich könnte also 2 tabellen kreieren.
Tabelle „b“ (parent), und die referierende „a“ (child).
Wenn ich jetzt einen Datensatz in „b“ anlege, könnte also ein Trigger dafür sorgen, dass „geleichzeitig“ ein Datensatz in „a“ erzeugt wird, der automatisch die id des in „b“ erzeugten Satzes enthält und somit seine Verknüpfung erhält?!?
Oracle - kein Problem (sag ich jetzt mal so einfach)
SQL-Server - mit deferrable Constaints sicher auch
MySQL - was sind Trigger?
Access - Hahahahaaaaaaaaa
Welche DB nimmst Du?
Gruß
Peter
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Oracle - kein Problem (sag ich jetzt mal so einfach)
SQL-Server - mit deferrable Constaints sicher auch
MySQL - was sind Trigger?
Access - Hahahahaaaaaaaaa
Welche DB nimmst Du?
Mysql
hat seit Version 5.x(?) jetzt Views und Trigger … :o)
(werd´s zumindest mal ausprobieren obs so funktioniert wie ich´s mir vorstelle)
Gruß
Peter
Hallo,
und danke für die Antworten.
Haben mir weitergeholfen - glaube ich :o)
D.h., ich könnte also 2 tabellen kreieren.
Tabelle „b“ (parent), und die referierende „a“ (child).
Wenn ich jetzt einen Datensatz in „b“ anlege, könnte also ein
Trigger dafür sorgen, dass „geleichzeitig“ ein Datensatz in
„a“ erzeugt wird, der automatisch die id des in „b“ erzeugten
Satzes enthält und somit seine Verknüpfung erhält?!?
Der Foreign Key eines Datensatzes der Tabelle „a“ verweist auf
einen Primary-Key eines Datensatzes in Tabelle „b“ und
verbindet so beide miteinander.
wo der primary key als Quelle für den foreign key steht, da ist das parent. Beim Antworten ist meine Logik Amok gelaufen: Ich käme nicht auf die Idee, erst das child in die Diskussion zu werfen und dann das parent ))
D.h., ich könnte also 2 tabellen kreieren.
Tabelle „b“ (parent), und die referierende „a“ (child).
das könntest Du.
Wenn ich jetzt einen Datensatz in „b“ anlege, könnte also ein
Trigger dafür sorgen, dass „geleichzeitig“ ein Datensatz in
„a“ erzeugt wird, der automatisch die id des in „b“ erzeugten
Satzes enthält und somit seine Verknüpfung erhält?!?
Wozu sollte das gut sein? b heiße zB Bestellung, a Bestellposition. Dann legst Du zur Bestellung eine leere Bestellposition an, die außer der ID des parents nichts enthält. Und dann?
oder (denkbares Bsp. …)
Adressdaten stehen in der Parent + Infos zu den Adressdaten in der Child.
Adressdaten sind vorhanden und werden eingespielt.
Die Infos sollen nachträglich zugefügt werden.
Jetzt hat also - nach dem Einfügen - jede Adresse eine Verknüpfung mit einem leeren Info-Datensatz.
Die Daten-Bearbeiter sehen über eine view die ausgewählten Adress- und Infodaten und können sie bearbeiten ohne dass sie eigene Datensätze anlegen können müssen.
(über views kann man in mysql editieren etc.)
Gruß
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
)
))