Fremdschlüssel

Auf dieser Seite werden Fremdschlüssel in Spanner beschrieben und wie Sie sie verwenden können, um die referenzielle Integrität in Datenbanken mit GoogleSQL- und PostgreSQL-Dialekt zu erzwingen.

Mit Fremdschlüsseln werden Beziehungen zwischen Tabellen definiert. Spanner stellt sicher, dass die Datenintegrität dieser Beziehungen aufrechterhalten wird.

Stellen Sie sich vor, Sie sind der Lead-Entwickler für ein E-Commerce-Unternehmen. Sie entwerfen eine Datenbank zur Verarbeitung von Kundenaufträgen. Die Datenbank muss Informationen über jede Bestellung, jeden Kunden und jedes Produkt speichern. Abbildung 1 zeigt die grundlegende Datenbankstruktur für die Anwendung.

Grundstruktur der Auftragsverarbeitungsdatenbank.

Abbildung 1. Diagramm einer Auftragsverarbeitungsdatenbank

Sie definieren eine Customers-Tabelle zum Speichern von Kundeninformationen, eine Orders-Tabelle zur Nachverfolgung aller Bestellungen und eine Products-Tabelle zum Speichern von Informationen zu jedem Produkt.

Abbildung 1 zeigt auch Links zwischen den Tabellen, die den folgenden realen Beziehungen zugeordnet sind:

  • Ein Kunde gibt eine Bestellung auf.

  • Es wird eine Bestellung für ein Produkt aufgegeben.

Sie entscheiden, dass Ihre Datenbank die folgenden Regeln erzwingen soll, um sicherzustellen, dass Bestellungen in Ihrem System gültig sind.

  • Sie können keinen Auftrag für einen Kunden erstellen, der nicht existiert.

  • Ein Kunde kann keine Bestellung für ein Produkt aufgeben, das Sie nicht führen.

Wenn Sie diese Regeln oder Einschränkungen erzwingen, sorgen Sie für die referenzielle Integrität Ihrer Daten. Wenn eine Datenbank die referenzielle Integrität aufrechterhält, schlagen alle Versuche fehl, ungültige Daten hinzuzufügen, die zu ungültigen Verknüpfungen oder Verweisen zwischen Daten führen würden. Die referenzielle Integrität verhindert Nutzerfehler. Spanner erzwingt die referenzielle Integrität durch Fremdschlüssel.

Referenzielle Integrität mit Fremdschlüsseln erzwingen

Im Folgenden wird das Beispiel für die Bestellabwicklung noch einmal betrachtet, wobei dem Design weitere Details hinzugefügt wurden (siehe Abbildung 2).

Datenbankschema mit Fremdschlüsseln

Abbildung 2. Diagramm eines Datenbankschemas mit Fremdschlüsseln

Im Design werden jetzt in jeder Tabelle Spaltennamen und -typen angezeigt. In der Tabelle Orders sind auch zwei Fremdschlüsselbeziehungen definiert. FK_CustomerOrder stellt sicher, dass alle Zeilen in Orders ein gültiges CustomerID haben. Der Fremdschlüssel FK_ProductOrder sorgt dafür, dass alle ProductID-Werte in der Tabelle Orders gültig sind. In der folgenden Tabelle werden diese Einschränkungen den tatsächlichen Regeln zugeordnet, die erzwungen werden sollen.

Name des Fremdschlüssels Einschränkung Beschreibung aus der Praxis
FK_CustomerOrder Stellt sicher, dass alle Zeilen in Orders eine gültige CustomerID haben Ein gültiger Kunde gibt eine Bestellung auf
FK_ProductOrder Stellt sicher, dass alle Zeilen in Orders eine gültige ProductID haben Es wurde eine Bestellung für ein gültiges Produkt aufgegeben

Spanner schlägt jede Transaktion fehl, die versucht, eine Zeile in die Tabelle Orders einzufügen oder zu aktualisieren, deren CustomerID oder ProductID nicht in den Tabellen Customers und Products enthalten ist. Außerdem schlägt sie fehl, wenn versucht wird, Zeilen in den Tabellen Customers und Products zu aktualisieren oder zu löschen, wodurch die IDs in der Tabelle Orders ungültig werden. Weitere Informationen dazu, wie Spanner Einschränkungen validiert, finden Sie im Abschnitt Überprüfung der Transaktionsbeschränkung.

Eigenschaften von Fremdschlüsseln

Im Folgenden finden Sie eine Liste der Eigenschaften von Fremdschlüsseln in Spanner.

  • Die Tabelle, die den Fremdschlüssel definiert, ist die referenzierende Tabelle und die Spalten des Fremdschlüssels sind die referenzierenden Spalten.

  • Der Fremdschlüssel verweist auf die referenzierten Spalten der Tabelle referenziert.

  • Wie im Beispiel können Sie jede Einschränkung für einen externen Schlüssel benennen. Wenn Sie keinen Namen angeben, generiert Spanner einen Namen für Sie. Sie können den generierten Namen über die INFORMATION_SCHEMA von Spanner abfragen. Einschränkungsnamen gelten zusammen mit den Namen für Tabellen und Indexe für das Schema und müssen innerhalb des Schemas eindeutig sein.

  • Die Anzahl der verweisenden und referenzierten Spalten muss identisch sein. Die Reihenfolge ist wichtig. Die erste referenzierende Spalte verweist auf die erste referenzierte Spalte, die zweite auf die zweite.

  • Eine verweisende Spalte und ihr referenziertes Gegenstück müssen vom selben Typ sein. Sie müssen die Spalten indexieren können.

  • Fremdschlüssel können nicht für Spalten mit der Option allow_commit_timestamp=true erstellt werden.

  • Array-Spalten werden nicht unterstützt.

  • JSON-Spalten werden nicht unterstützt.

  • Ein Fremdschlüssel kann auf Spalten derselben Tabelle verweisen (ein sich selbst referenzierender Fremdschlüssel). Ein Beispiel ist eine Employee-Tabelle mit einer ManagerId-Spalte, die auf die EmployeeId-Spalte der Tabelle verweist.

  • Fremdschlüssel können auch zirkuläre Beziehungen zwischen Tabellen bilden, wobei sich zwei Tabellen direkt oder indirekt auf einander beziehen. Die referenzierte Tabelle muss vorhanden sein, bevor ein Fremdschlüssel erstellt werden kann. Das bedeutet, dass mindestens einer der Fremdschlüssel mit der Anweisung ALTER TABLE hinzugefügt werden muss.

  • Die referenzierten Schlüssel müssen eindeutig sein. Spanner verwendet das PRIMARY KEY der referenzierten Tabelle, wenn die referenzierten Spalten für einen Fremdschlüssel mit den Primärschlüsselspalten der referenzierten Tabelle übereinstimmen. Wenn Spanner den Primärschlüssel der referenzierten Tabelle nicht verwenden kann, wird ein UNIQUE NULL_FILTERED INDEX für die referenzierten Spalten erstellt.

  • Spanner kann auch den Primärschlüssel der Referenztabelle verwenden, obwohl dies seltener vorkommt. Ist dies nicht der Fall, wird von Spanner ein Wert von NULL_FILTERED INDEX für die referenzierenden Spalten erstellt.

  • Bei Fremdschlüsseln werden keine von Ihnen erstellten sekundären Indexe verwendet. Stattdessen erstellen sie ihre eigenen Sicherungsindizes. Backing-Indexe können in Abfrageauswertungen verwendet werden, einschließlich expliziter force_index-Anweisungen. Sie können die Namen der Sicherungsindizes über INFORMATION_SCHEMA von Spanner abfragen. Weitere Informationen finden Sie unter Indexe sichern.

Fremdschlüssel definieren

Sie erstellen und entfernen Fremdschlüssel aus Ihrer Spanner-Datenbank mithilfe von DDL. Mit der Anweisung CREATE TABLE fügen Sie einer neuen Tabelle Fremdschlüssel hinzu. In ähnlicher Weise können Sie mit der Anweisung ALTER TABLE einen Fremdschlüssel zu einer vorhandenen Tabelle hinzufügen oder daraus entfernen. Im Folgenden finden Sie ein Beispiel für die Erstellung einer neuen Tabelle mit einem Fremdschlüssel.

GoogleSQL

CREATE TABLE Orders (
OrderID INT64 NOT NULL,
CustomerID INT64 NOT NULL,
Quantity INT64 NOT NULL,
ProductID INT64 NOT NULL,
CONSTRAINT FK_CustomerOrder FOREIGN KEY (CustomerID) REFERENCES Customers (CustomerID)
) PRIMARY KEY (OrderID);

PostgreSQL

CREATE TABLE Orders (
OrderID BIGINT NOT NULL,
CustomerID BIGINT NOT NULL,
Quantity BIGINT NOT NULL,
ProductID BIGINT NOT NULL,
CONSTRAINT FK_CustomerOrder FOREIGN KEY (CustomerID) REFERENCES Customers (CustomerID),
PRIMARY KEY (OrderID)
);

Weitere Beispiele zum Erstellen und Verwalten von Fremdschlüsseln finden Sie unter Fremdschlüsselbeziehungen erstellen und verwalten.

Fremdschlüsselaktionen

Mit Fremdschlüsselaktionen wird festgelegt, was mit der eingeschränkten Spalte passiert, wenn die Spalte, auf die sie verweist, gelöscht oder aktualisiert wird. Spanner unterstützt die Verwendung der Aktion ON DELETE CASCADE. Wenn Sie mit der Aktion ON DELETE CASCADE für Fremdschlüssel eine Zeile löschen, die einen referenzierten Fremdschlüssel enthält, werden in derselben Transaktion auch alle Zeilen gelöscht, die auf diesen Schlüssel verweisen.

Sie können einen Fremdschlüssel mit einer Aktion hinzufügen, wenn Sie Ihre Datenbank mit DDL erstellen. Mit der Anweisung CREATE TABLE können Sie einer neuen Tabelle Fremdschlüssel mit einer Aktion hinzufügen. In ähnlicher Weise können Sie mit der Anweisung ALTER TABLE einer vorhandenen Tabelle eine Fremdschlüsselaktion hinzufügen oder eine Fremdschlüsselaktion daraus entfernen. Im Folgenden finden Sie ein Beispiel für die Erstellung einer neuen Tabelle mit einer Fremdschlüsselaktion.

GoogleSQL

CREATE TABLE Customers (
CustomerId INT64 NOT NULL,
CustomerName STRING(MAX) NOT NULL,
) PRIMARY KEY(CustomerId);

CREATE TABLE ShoppingCarts (
CartId INT64 NOT NULL,
CustomerId INT64 NOT NULL,
CustomerName STRING(MAX) NOT NULL,
CONSTRAINT FKShoppingCartsCustomers FOREIGN KEY(CustomerId, CustomerName)
  REFERENCES Customers(CustomerId, CustomerName) ON DELETE CASCADE,
) PRIMARY KEY(CartId);

PostgreSQL

CREATE TABLE Customers (
CustomerId bigint NOT NULL,
CustomerName character varying(1024) NOT NULL,
PRIMARY KEY(CustomerId)
);

CREATE TABLE ShoppingCarts (
CartId bigint NOT NULL,
CustomerId bigint NOT NULL,
CustomerName character varying(1024) NOT NULL,
PRIMARY KEY(CartId),
CONSTRAINT fkshoppingcartscustomers FOREIGN KEY (CustomerId, CustomerName)
  REFERENCES Customers(CustomerId, CustomerName) ON DELETE CASCADE
);

Im Folgenden finden Sie eine Liste der Eigenschaften von Fremdschlüsselaktionen in Spanner.

  • Fremdschlüsselaktionen sind entweder ON DELETE CASCADE oder ON DELETE NO ACTION.

  • Sie können INFORMATION_SCHEMA abfragen, um Fremdschlüsseleinschränkungen mit einer Aktion zu finden.

  • Das Hinzufügen einer Fremdschlüsselaktion zu einer vorhandenen Fremdschlüsseleinschränkung wird nicht unterstützt. Sie müssen eine neue Fremdschlüsseleinschränkung mit einer Aktion hinzufügen.

Lang andauernde Schemaänderungen

Das Hinzufügen eines Fremdschlüssels zu einer vorhandenen Tabelle oder das Erstellen einer neuen Tabelle mit einem Fremdschlüssel kann zu lang andauernden Vorgängen führen. Im Fall einer neuen Tabelle kann die Tabelle erst geschrieben werden, wenn der lange laufende Vorgang abgeschlossen ist.

Bei einer neuen Tabelle mit einem Fremdschlüssel muss Spanner die referenzierten Indexe nach Bedarf für jeden Fremdschlüssel anpassen.

Bei einer vorhandenen Tabelle mit einem Fremdschlüssel muss Spanner die referenzierenden und referenzierten Indexe nach Bedarf auffüllen. Darüber hinaus validiert Spanner vorhandene Daten in der Tabelle, um sicherzustellen, dass sie der referenziellen Integritätsbedingung des Fremdschlüssels entsprechen. Die Schemaänderung schlägt fehl, wenn Daten ungültig sind.

Das Hinzufügen einer Fremdschlüsselaktion zu einer vorhandenen Einschränkung wird nicht unterstützt. Sie sollten Folgendes tun:

  1. Fügen Sie eine neue Einschränkung mit der erforderlichen Aktion hinzu.
  2. Löschen Sie die ältere Einschränkung, die keine Aktion enthält.

So wird ein Long-running Alter Constraint Operation-Problem vermieden. Nachdem Sie den neuen Fremdschlüssel mit der Aktion ON DELETE CASCADE erstellt haben, ist der Nettoeffekt beider Einschränkungen DELETE CASCADE. Wenn Sie eine Einschränkung aufheben, werden möglicherweise auch die Sicherungsindizes für den Fremdschlüssel gelöscht, wenn die Indizes nicht in anderen Fremdschlüsseleinschränkungen verwendet werden. Wenn der Nutzer dieselbe Fremdschlüsseleinschränkung später mit einer Aktion hinzufügt, sind möglicherweise langwierige Vorgänge erforderlich, z. B. das Auffüllen von Indexen, die Validierung von Eindeutigkeitsindexeinschränkungen und die Validierung von Fremdschlüsselreferenzeinschränkungen.

Eine der oben genannten Schemaänderungen kann fehlschlagen, wenn der Index, auf den verwiesen wird, aufgrund eines UNIQUE-Einschränkungsverstoßes nicht erstellt werden kann.

Sie können INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS.SPANNER_STATE abfragen, um den Erstellungsstatus des Fremdschlüssels zu überprüfen.

Einschränkungsvalidierung

Spanner prüft die Bedingungen für Fremdschlüssel, wenn eine Transaktion Commit ausgeführt wird oder wenn die Auswirkungen von Schreibvorgängen für nachfolgende Vorgänge in der Transaktion sichtbar gemacht werden.

Ein Wert, der in die Referenzspalte eingefügt wird, wird mit den Werten der referenzierten Tabelle und der referenzierten Spalten abgeglichen. Zeilen mit NULL-Verweiswerten werden nicht aktiviert, das heißt, sie können der Verweistabelle hinzugefügt werden.

Spanner validiert alle anwendbaren referenziellen Fremdschlüsseleinschränkungen, wenn versucht wird, Daten entweder über DML-Anweisungen oder über ein API zu aktualisieren. Alle ausstehenden Änderungen werden rückgängig gemacht, wenn Einschränkungen ungültig sind.

Die Validierung erfolgt unmittelbar nach jeder DML-Anweisung. Sie müssen beispielsweise die referenzierte Zeile einfügen, bevor Sie die entsprechenden Zeilen einfügen. Bei Verwendung einer Mutations-API werden Mutationen zwischengespeichert, bis die Transaktion festgeschrieben wird. Die Validierung des Fremdschlüssels wird so lange zurückgestellt, bis die Transaktion festgeschrieben wird. In diesem Fall ist es zulässig, zuerst die referenzierenden Zeilen einzufügen.

Jede Transaktion wird auf Änderungen geprüft, die sich auf die Einschränkungen von Fremdschlüsseln auswirken. Für diese Bewertungen sind möglicherweise zusätzliche Anforderungen an den Server erforderlich. Sicherungsindizes benötigen außerdem zusätzliche Verarbeitungszeit, um Transaktionsänderungen auszuwerten und die Indexe zu verwalten. Für jeden Index ist zusätzlicher Speicher erforderlich.

Indizes sichern

Bei Fremdschlüsseln werden keine von Nutzern erstellten Indexe verwendet. Sie erstellen ihre eigenen Sicherungsindizes.

Spanner kann für jeden Fremdschlüssel bis zu zwei sekundäre Sicherungsindizes erstellen, einen für die verweisenden Spalten und einen zweiten für die referenzierten Spalten. Ein Fremdschlüssel verweist jedoch in der Regel auf die Primärschlüssel der referenzierten Tabelle, sodass der zweite Index in der referenzierten Tabelle in der Regel nicht benötigt wird.

Der Sicherungsindex für die referenzierte Tabelle ist ein UNIQUE NULL_FILTERED-Index. Das Erstellen des Fremdschlüssels schlägt fehl, wenn vorhandene Daten gegen die Eindeutigkeitsbeschränkung des Index verstoßen. Der Sicherungsindex für die referenzierende Tabelle beträgt NULL_FILTERED.

Wenn zwei oder mehr Fremdschlüssel denselben Sicherungsindex erfordern, erstellt Spanner einen einzigen Index für alle. Die Sicherungsindizes werden gelöscht, wenn die sie verwendenden Fremdschlüssel gelöscht werden. Nutzer können die Backing-Indexe nicht ändern oder löschen.

Spanner verwendet das Informationsschema für jede Datenbank, um Metadaten zu unterstützenden Indexen zu speichern. Zeilen in INFORMATION_SCHEMA.INDEXES mit dem SPANNER_IS_MANAGED-Wert true beschreiben Indexe für die Sicherung.

Außer bei SQL-Abfragen, die das Informationsschema direkt aufrufen, werden in der Google Cloud Console keine Informationen zu den unterstützenden Indexen einer Datenbank angezeigt.

Lange dauernde Löschkaskadenaktion

Wenn Sie eine Zeile aus einer referenzierten Tabelle löschen, muss Spanner alle Zeilen in den referenzierten Tabellen löschen, die auf die gelöschte Zeile verweisen. Dies kann zu einem Dominoeffekt führen, bei dem ein einzelner Löschvorgang zu Tausenden anderer Löschvorgänge führt. Wenn Sie einer Tabelle eine Fremdschlüsseleinschränkung mit der Aktion „Kettenlöschung“ hinzufügen oder eine Tabelle mit Fremdschlüsseleinschränkungen mit der Aktion „Kettenlöschung“ erstellen, können Löschvorgänge verlangsamt werden.

Mutationslimit für die Fremdschlüssel-Löschkaskade überschritten

Das Löschen einer großen Anzahl von Einträgen mithilfe einer Löschkaskade für einen Fremdschlüssel kann sich auf die Leistung auswirken. Das liegt daran, dass beim Löschen eines Datensatzes alle zugehörigen Datensätze gelöscht werden. Wenn Sie eine große Anzahl von Einträgen mithilfe einer Löschkaskade für einen Fremdschlüssel löschen möchten, müssen Sie die Zeilen aus den untergeordneten Tabellen explizit löschen, bevor Sie die Zeile aus den übergeordneten Tabellen löschen. So wird verhindert, dass die Transaktion aufgrund des Mutationslimits fehlschlägt.

Vergleich von Fremdschlüsseln und Tabellenverschränkung

Die Tabellenverschränkung von Spanner ist eine gute Wahl für viele über-/untergeordnete Beziehungen, bei denen der Primärschlüssel der untergeordneten Tabelle die Primärschlüsselspalten der übergeordneten Tabelle enthält. Das Speichern von untergeordneten und übergeordneten Zeilen an einem Ort kann die Leistung erheblich verbessern.

Fremdschlüssel sind eine allgemeinere über-/untergeordnete Lösung, die zusätzliche Anwendungsfälle behandelt. Sie sind nicht auf Primärschlüsselspalten beschränkt und Tabellen können mehrere Fremdschlüsselbeziehungen haben, die in einigen Beziehungen als übergeordnete und in anderen als untergeordnete Beziehungen gelten. Eine Fremdschlüsselbeziehung impliziert jedoch nicht, dass sich die Tabellen auf der Speicherebene befinden.

Betrachten wir ein Beispiel mit einer Orders-Tabelle, die so definiert ist:

Datenbankschema mit Fremdschlüsseln

Abbildung 3. Diagramm unseres Datenbankschemas mit Fremdschlüsseln

Das Design in Abbildung 3 unterliegt einigen Einschränkungen. Beispielsweise kann jeder Auftrag nur ein Auftragselement enthalten.

Angenommen, Ihre Kunden möchten pro Bestellung mehr als ein Produkt bestellen können. Sie können Ihr Design verbessern, indem Sie eine OrderItems-Tabelle einführen, die einen Eintrag für jedes Produkt enthält, das der Kunde bestellt hat. Sie können einen weiteren Fremdschlüssel einführen, um diese neue 1: n-Beziehung zwischen Orders und OrderItems darzustellen. Sie wissen aber auch, dass Sie häufig Abfragen für Aufträge und ihre jeweiligen Auftragselemente ausführen möchten. Da die gemeinsame Speicherung dieser Daten die Leistung steigert, sollten Sie die über-/untergeordnete Beziehung mithilfe der Tabellenverschränkungsfunktion von Spanner erstellen.

So definieren Sie die Tabelle OrderItems, die mit Orders verschränkt ist.

GoogleSQL

CREATE TABLE OrderItems (
OrderID INT64 NOT NULL,
ProductID INT64 NOT NULL,
Quantity INT64 NOT NULL,
FOREIGN KEY (ProductID) REFERENCES Products (ProductID)
) PRIMARY KEY (OrderID, ProductID),
INTERLEAVE IN PARENT Orders ON DELETE CASCADE;

PostgreSQL

CREATE TABLE OrderItems (
OrderID BIGINT NOT NULL,
ProductID BIGINT NOT NULL,
Quantity BIGINT NOT NULL,
FOREIGN KEY (ProductID) REFERENCES Products (ProductID),
PRIMARY KEY (OrderID, ProductID)
) INTERLEAVE IN PARENT Orders ON DELETE CASCADE;

Abbildung 4 ist eine visuelle Darstellung des aktualisierten Datenbankschemas als Ergebnis der Einführung dieser neuen Tabelle, OrderItems, verschachtelt mit Orders. Hier sehen Sie auch die 1:n-Beziehung zwischen diesen beiden Tabellen.

Datenbankschema, das eine 1:n-Beziehung zwischen Orders und der neuen, verschränkten OrderItems-Tabelle zeigt

Abbildung 4. Hinzufügen einer verschränkten OrderItems-Tabelle

In dieser Konfiguration können mehrere OrderItems-Einträge in jedem Auftrag vorhanden sein und die OrderItems-Einträge für jeden Auftrag sind verschränkt und befinden sich daher zusammen mit den Aufträgen. Das physische Verschränken von Orders und OrderItems auf diese Weise kann die Leistung verbessern, indem die Tabellen effektiv vorab zusammengeführt werden und Sie zusammen auf ähnliche Zeilen zugreifen können, während Zugriffe auf das Laufwerk minimiert werden. Spanner kann beispielsweise Joins lokal nach Primärschlüssel durchführen, um den Zugriff auf das Laufwerk und den Netzwerkverkehr zu minimieren.

Wenn die Anzahl der Mutationen in einer Transaktion 80.000 überschreitet, schlägt die Transaktion fehl. Solche umfangreichen kaskadierenden Löschvorgänge funktionieren gut für Tabellen mit einer Beziehung vom Typ „in übergeordnete Tabelle verschachtelt“, aber nicht für Tabellen mit einer Fremdschlüsselbeziehung. Wenn Sie eine Fremdschlüsselbeziehung haben und eine große Anzahl von Zeilen löschen müssen, sollten Sie zuerst die Zeilen aus den untergeordneten Tabellen explizit löschen.

Wenn Sie eine Nutzertabelle mit einer Fremdschlüsselbeziehung zu einer anderen Tabelle haben und das Löschen einer Zeile aus der referenzierten Tabelle das Löschen von Millionen von Zeilen auslöst, sollten Sie Ihr Schema mit einer Löschkaskadenaktion mit „in übergeordnetem Element verschachtelt“ entwerfen.

Vergleichstabelle

In der folgenden Tabelle sind die Vergleiche von Fremdschlüsseln und Tabellenverschränkung zusammengefasst. Anhand dieser Informationen können Sie entscheiden, was für Ihr Design am besten geeignet ist.

Über- / Untergeordnet-Beziehungstyp Tabellen verschränken Fremdschlüssel
Kann Primärschlüssel verwenden Ja Ja
Kann Spalten ohne Primärschlüssel verwenden Nein Ja
Anzahl der unterstützten Eltern 0 .. 1 0 .. N
Speichert übergeordnete und untergeordnete Daten zusammen Ja Nein
Unterstützt das Löschen von Kaskaden Ja Ja
Null-Abgleichmodus Übergibt, wenn sich alle referenzierenden Werte nicht von den referenzierten Werten unterscheiden.
Nullwerte unterscheiden sich nicht von Nullwerten. Nullwerte unterscheiden sich von Nicht-Nullwerten.
Übergibt, wenn verweisende Werte null sind.
Wird übergeben, wenn alle verweisenden Werte ungleich null sind und die referenzierte Tabelle eine Zeile mit Werten aufweist, die den verweisenden Werten entsprechen.
Schlägt fehl, wenn keine übereinstimmende Zeile gefunden wurde.
Zeitpunkt der Durchsetzung Pro Vorgang bei Verwendung der mutation API.
Pro Anweisung bei Verwendung von DML.
Pro Transaktion bei Verwendung der Mutation API
Pro Anweisung bei Verwendung von DML.
Kann entfernt werden Nein. Tabellenverschränkungen können nach dem Erstellen nicht entfernt werden, es sei denn, Sie löschen die gesamte untergeordnete Tabelle. Ja

Nächste Schritte