Hilfe bei der Erstellung eines Fremdschlüßels

[boka]

Hallo,

ich habe Probleme bei der Erstellung eines Fremdschlüßels.
In einer Datenbank gibt es die Tabellen Adressen, Personen und Kommunikation. Kommunikation solle alles Kommunikationsdaten für Adressen und Personen enthalten.
Da der Adressen und Personen die gleichen Schlüßel haben können gibt es das Feld ReferenzType. ReferenzType A = Adressen ReferenzType P = Personen.

Leider bekomme ich einen Fehler bei der Erstellung des Fremdschlüßels, da er die Konstante nicht akzeptiert.

Die Anweisungen sollten so aussehen:
[highlight=sql]
ALTER TABLE [dbo].[dhKommunikation] *WITH CHECK ADD *CONSTRAINT [FK_dhKommunikation_dhAdressen] FOREIGN KEY([ReferenzID],[ReferenzType])
REFERENCES [dbo].[dhAdressen] ([AdresseID],'A')
ALTER TABLE [dbo].[dhKommunikation] *WITH CHECK ADD *CONSTRAINT [FK_dhKontakte_dhKunden] FOREIGN KEY([ReferenzID],[ReferenzType])
REFERENCES [dbo].[dhKontakte] ([KontakteID],'P')
[/highlight]
Hat jemand einen Tipp wie man das Problem löst?

Grüsse

Bernd

[Ralf Jansen]

An der Stelle gehen nur Spalten der Fremdtabelle keine Konstanten. In SQL würde man das mit Assertions lösen. Assertions sind aber ein eher selten anzutreffendes (und auch daher selten benutztes) Feature in Datenbanken. Der scheinbar von die verwendete Sql Server kennt das zumindest nicht.

Ohne irgendeinen Hilfskonstrukt der Einfluß auf die Verwendung hat wirst du da wohl nicht weiterkommen. Aber wieso ist es eine gemeinsame Tabelle wenn ein Teil der Daten garantiert mit Tabelle A verknüpft ist und die anderen Daten garantiert mit Daten aus Tabelle B? Da würde ich auch einfach 2 Tabellen nehmen wenn der einzige Zusammenhang ansonsten ist das sie die gleiche Metadatenstruktur haben. Wenn man die gemeinsam für irgendwas braucht könnte man die beiden Tabellen ja immer noch über einen Union View zusammenführen.

[defo]

Ich kenne auch kein RDBMS, das sowas anbietet (Muss aber nichts heißen). Sonst wären es wohl auch eher objektrelationale Systeme statt nur relationale Systeme...
Habe sowas auch schon vermisst.

Rein aus Neugier, was passiert, wenn Du in der "references" Definition die Konstanten weglässt?

M.E. kann man das am ehsten zu Fuß über einen Insert/Update Trigger lösen, der typabhängig in der einen oder anderen Tabelle nachschlägt.

[Ralf Jansen]

Rein aus Neugier, was passiert, wenn Du in der "references" Definition die Konstanten weglässt?

Bei der Überlegung darüber frag ich mich gerade ob nicht einfach die Referenzierung falsch herum ist
Kommunikation soll eine Referenz auf Adressen oder Kontakte haben.
Er schreibt aber ja selbst

Kommunikation solle alles Kommunikationsdaten für Adressen und Personen enthalten.

Wenn ich das Umgangssprachliche übersetze ist Kommunikationsdaten was untergeordnetes von Adressen und Personen.
Also sollte Adressen und Personen jeweils eine Referenz auf Kommunikationsdaten haben und an Addressen udn Personen läßt sich jeweils natürlich simpel der Foreign Key Constraint ohne Konstanten anlegen.

[defo]

@Ralf
Das seh ich anders.
Eine Adresse hat mehrere Kommunikationssätze. Der Verweis geht also von n Kommunikation auf die 1 Adresse, ebenso bei Person.
Man könnte das natürlich einfach in separate Felder packen, bedeutet aber immer, dass eine Referenz leer bleibt (bleiben muss - Constraintabsicherung).
Auch nicht tragisch außer es geht um viele viele Daten, wo man sich ne Spalte sparen könnte. Wäre beim Thema "Kommunikation" durchaus denkbar.

[boka]

Hallo,

danke für eure Hilfe.

Eine Adresse bzw Person kann n Kommunikationsdaten haben. Da z.B. es eine Adresse mit Key 10 und eine Person mit Key 10 existieren kann darf ich den den references die Konstant nicht weg lassen.

Ich werde wohl den Weg mit den 2 Tabellen und einer Sicht nehmen. Das klingt am einfachsten für mich.

Danke

Bernd