Fremdschlüssel Referenzierung zusammengesetzter Tabelle

Question

Ich habe eine Tabellenstruktur. Ich bin mir nicht sicher, wie ich den besten Weg kreieren kann.

Grundsätzlich habe ich zwei Tabellen, TBLSystemItems und TblclientItems. Ich habe eine dritte Tabelle mit einer Spalte, in der ein "Element" verweist. Das Problem ist, dass diese Spalte entweder auf ein Systemelement oder ein Client -Element verweisen muss - es spielt keine Rolle, welche. Systemelemente haben Schlüssel im Bereich von 1..2^31, während Client -Elemente Schlüssel im Bereich -1 -1 ..- 2^31 haben, daher wird es niemals Kollisionen geben.

Immer wenn ich die Gegenstände abfragt, mache ich es durch eine Ansicht, die eine Vereinigung zwischen dem Inhalt der beiden Tabellen macht.

Daher möchte ich optimal eine Fremdschlüsselreferenz zum Ergebnis der Ansicht machen, da die Ansicht immer die Vereinigung der beiden Tabellen sein wird - und gleichzeitig die IDs einzigartig hält. Aber ich kann das nicht tun, da ich nicht auf eine Ansicht hinweisen kann.

Jetzt kann ich nur den fremden Schlüssel fallen lassen, und alles ist gut. Ich möchte jedoch eine Referenzüberprüfung und Kaskadierung von Löschen/Set -Null -Funktionen haben. Gibt es neben Triggern eine Möglichkeit, dies zu tun?

Answer 1

Entschuldigung für die späte Antwort, ich wurde von einem ernsthaften Fall von Weekenditis getroffen.

In Bezug auf die Verwendung einer dritten Tabelle, die PKs sowohl aus Client- als auch von Systemtabellen einbezieht, mag ich das nicht, da dies die Synchronisation übermäßig kompliziert und meine App immer noch erfordert, um die dritte Tabelle zu kennen.

Ein weiteres Problem, das aufgetreten ist, ist, dass ich eine dritte Tabelle habe, in der ein Element verweisen muss - entweder System oder Client, es spielt keine Rolle. Wenn die Tabellen im Grunde getrennt sind, muss ich zwei Spalten haben, eine ClientItemid und eine SystemItemid, die jeweils eine Einschränkung für jeden ihrer Tabellen mit Nullabilität haben - eher hässlich.

Am Ende habe ich eine andere Lösung gewählt. Das gesamte Problem bestand darin, neue Systemelemente leicht in die Tabellen zu synchronisieren, ohne sich mit Client -Elementen zu beschäftigen, Kollisionen zu vermeiden und so weiter.

Am Ende habe ich nur eine einzelne Tabelle erstellt, Elemente. Die Elemente haben eine Bitspalte mit dem Namen "SystemItem", die das Offensichtliche definiert. In meiner Entwicklungs- / Systemdatenbank habe ich die PK als Int -Identität (1,1). Nachdem die Tabelle in der Client-Datenbank erstellt wurde, wird der Identitätsschlüssel in (-1, -1) geändert. Das bedeutet, dass Clientelemente negativ gehen, während Systemelemente positiv gehen.

Für Synchronisationen ignoriere ich im Grunde alles mit (SystemItem = 1), während ich den Rest mit dem Identitätsinserct eins synchronisiert habe. Daher kann ich mich synchronisieren, während ich Client -Elemente vollständig ignoriere und Kollisionen vermeidet. Ich kann auch nur eine "Element" -Tabelle verweisen, die sowohl Client- als auch Systemelemente abdeckt. Das einzige, was Sie beachten sollten, ist die Behebung des Standard -Clustered -Schlüssels, sodass er abfällt, um alle Arten von Seitenumstrukturierungen zu vermeiden, wenn der Client neue Elemente einfügt (Client -Updates gegen Systemaktualisierungen sind 99%/1%).

Answer 2

Sie können eine eindeutige ID (DB generiert - Sequenz, automatisch usw.) für die Tabelle erstellen, die Elemente verweist, und zwei zusätzliche Spalten (erstellen Sie zwei zusätzliche Spalten (TBLSYSTEMITEMSFK und tBlclientItemsfk) wo Sie auf die Systemelemente bzw. Clientelemente verweisen - - etwas Datenbanken ermöglichen es Ihnen, einen Fremdschlüssel zu haben, der ist Nullbar.

Wenn Sie ein ORM verwenden, können Sie auch die Client -Elemente und -Systemelemente leicht unterscheiden (auf diese Weise müssen Sie keine negativen Kennungen benötigen, um ID -Überlappungen zu verhindern), basierend auf Spalteninformationen.

Mit etwas mehr Bakcground/Kontext ist es wahrscheinlich einfacher, eine optimale Lösung zu bestimmen.

Answer 3

Sie benötigen wahrscheinlich einen Tisch mit der Aufschrift tBlitems, die einfach alle Primärschlüssel der beiden Tabellen speichern. Das Einfügen von Elementen erfordert zwei Schritte, um sicherzustellen, dass die PK -Tabelle in die Tabelle TBLItems eingegeben wird, wenn ein Element in die Tabelle TBLSystemEMs eingegeben wird.

Die dritte Tabelle hat dann einen FK zu tBlitems. In gewisser Weise ist Tblitems ein Elternteil der anderen beiden Elementtabellen. Um einen Artikel abzufragen, wäre es notwendig, einen Join zwischen TBlitems, TBLSystemInems und TblclientItems zu erstellen.

Bearbeiten für einen Kommentar unten] Wenn die TBLSystemInem und TBlclientItems ihre eigene PK kontrollieren, können Sie sie trotzdem lassen. Sie würden wahrscheinlich zuerst in TBLSystemItems einfügen und dann in TBLItems einfügen. Wenn Sie eine Vererbungsstruktur mit einem Tool wie Hibernate implementieren, haben Sie so etwas.

Answer 4

Fügen Sie eine Tabelle namens Elemente mit einer PK -ItemID hinzu, und eine einzelne Spalte namens itemType = "System" oder "Client". Die Clientem -Tabelle PK (benannt ClientItemid) und SystemItems PK (mit dem Namen SystemItemid) sind beide auch FKs zu Elementen. Diese Beziehungen sind Null zu einer Beziehung (0-1)

In Ihrer dritten Tabelle, in der ein Element verweist, beziehen Sie sich nur auf die FK -Einschränkung auf die ItemID in dieser zusätzlichen (Element) Tabelle ...

Wenn Sie gespeicherte Prozeduren zum Implementieren von Einfügungen verwenden, lassen Sie einfach den gespeicherten Proc, der Elemente einfügt, die zuerst einen neuen Datensatz in die Elemente-Tabelle einfügen, und verwenden ClientItems (je nachdem, was es ist) als Teil desselben gespeicherten Proc-Aufrufs unter Verwendung des automatisch generierten (Identitäts-) Wertes, den das System in die Spalte Items Table ItemID eingefügt hat.

Dies nennt man "Subklasse"

Answer 5

Ich habe über Ihr Tischdesign rätselhaft. Ich bin mir nicht sicher, ob es richtig ist. Mir ist klar, dass die dritte Tabelle möglicherweise nur Detailinformationen liefert, aber ich kann nicht anders, als zu denken, dass der Hauptschlüssel tatsächlich der in Ihrer Artikeltabelle ist und die Fremdschlüssel die in Ihren System- und Client -Artikeltabellen sind. Sie müssen dann nur die richtigen Außenverbindungen vom Element zum System- und Client -Artikeltabellen machen, und alle Einschränkungen würden einwandfrei funktionieren.

Answer 6

Ich habe eine ähnliche Situation in einer Datenbank, die ich verwende. Ich habe einen "Kandidatenschlüssel" in jeder Tabelle, die ich entityId nenne. Wenn es dann eine Tabelle gibt, die sich auf Elemente in mehr als einem der anderen Tabellen beziehen muss, verwende ich EntityID, um auf diese Zeile zu verweisen. Ich habe eine Entitätstabelle, um alles zu überschreiten (so dass EntityID der Hauptschlüssel der Entitätstabelle ist und alle anderen EntityIDs fks sind), aber ich benutze die Entitätstabelle nicht sehr oft.