Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Arbeiten mit Fremdschlüsseleinschränkungen in Aurora DSQL

Mit Fremdschlüsseleinschränkungen in Aurora DSQL können Sie die referentielle Integritätslogik einer Anwendung in die Datenbank übertragen. Aurora DSQL unterstützt die AktionenNO ACTION,, RESTRICT CASCADESET NULL, und SET DEFAULT referentielle Aktionen. Es unterstützt auch die Typen MATCH FULL und MATCH SIMPLE Match sowie Beschränkungen für aufschiebbare Fremdschlüssel. Die vollständige Aufschlüsselung der Syntax finden Sie unter. Einschränkungen bei Fremdschlüsseln

Wie Aurora DSQL die referentielle Integrität beibehält

Aurora DSQL gewährleistet die referenzielle Integrität in zwei Schritten: Snapshot-Verifizierung während der Ausführung der Transaktion und Konfliktlösung zum Zeitpunkt der Übertragung. Zusammen garantieren diese Schritte, dass eine festgeschriebene Transaktion niemals gegen eine Fremdschlüsseleinschränkung verstößt.

Snapshot-Überprüfung. Jede Transaktion in Aurora DSQL wird mit einem konsistenten Snapshot der Datenbank ausgeführt, der zu ihrer Startzeit erstellt wurde. Wenn Sie eine referenzierende Zeile einfügen oder aktualisieren, liest Aurora DSQL die referenzierte Tabelle zum Startzeitpunkt Ihrer Transaktion, um zu bestätigen, dass der referenzierte Schlüssel existiert. Wenn Sie einen referenzierten Schlüssel löschen oder aktualisieren, liest Aurora DSQL die Referenztabelle im Transaktions-Snapshot. Es bestätigt, dass keine referenzierenden Zeilen existieren (fürRESTRICT) oder dass die Operation keine verwaisten Zeilen (for) hinterlässt. NO ACTION Da bei dieser Überprüfung der Snapshot zur Startzeit der Transaktion gelesen wird, anstatt eine Sperre zu setzen, können andere Transaktionen die referenzierten und referenzierenden Tabellen weiterhin parallel ändern.

Commit-time Auflösung. Die Snapshot-Verifizierung stellt sicher, dass die Beschränkung zur Startzeit der Transaktion gilt, aber nicht zwischen Start und Commit. Eine gleichzeitige Transaktion kann die referenzierte Zeile löschen oder eine widersprüchliche Referenzzeile einfügen, nachdem Ihre Transaktion gestartet wurde. Um diese Konflikte zu lösen, wendet Aurora DSQL die KEY SHARE Klausel implizit auf referenzierte Zeilen an, um festzustellen, ob eine gleichzeitige Änderung Ihren Snapshot ungültig gemacht hat. Wenn Aurora DSQL einen Konflikt erkennt, schlägt die Transaktion mit einem Serialisierungsfehler fehl. Weitere Informationen darüber, wie sich die KEY SHARE Klausel auf gleichzeitige Transaktionen auswirkt, finden Sie unter. Parallelitätssteuerung in Aurora DSQL

Beispielszenarien

Im folgenden Szenario weist die orders Tabelle eine Fremdschlüsseleinschränkung in ihrer product_id Spalte auf, die auf die products Tabelle verweist. Dadurch wird products die referenzierte Tabelle und orders die referenzierende Tabelle gebildet.

CREATE TABLE products (
    product_id integer PRIMARY KEY,
    name text,
    price numeric
);
CREATE TABLE orders (
    order_id integer PRIMARY KEY,
    product_id integer REFERENCES products,
    quantity integer
);
INSERT INTO products VALUES (1, 'Widget', 9.99);
    

Konflikt: gleichzeitiges Löschen und Einfügen

In diesem Szenario löscht eine Sitzung eine referenzierte Zeile, während eine andere Sitzung eine referenzierende Zeile einfügt.

-- Session A
BEGIN;
DELETE FROM products WHERE product_id = 1;

-- Session B
BEGIN;
INSERT INTO orders VALUES (100, 1, 5);

-- Session A
COMMIT;  -- succeeds

-- Session B
COMMIT;  -- fails with serialization error
ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001)

Beide Sitzungen werden gleichzeitig ausgeführt. Aurora DSQL löst den Konflikt beim Commit. Sie können nicht mit einer Bestellung enden, die auf ein gelöschtes Produkt verweist.

Kein Konflikt: Aktualisierung einer Spalte, die keine Schlüsselinformationen enthält

In diesem Szenario aktualisiert eine Sitzung eine Nicht-Schlüsselspalte in der referenzierten Zeile, während eine andere Sitzung eine referenzierende Zeile einfügt.

-- Session A
BEGIN;
UPDATE products SET name = 'Super Widget' WHERE product_id = 1;

-- Session B
BEGIN;
INSERT INTO orders VALUES (101, 1, 3);

-- Session A
COMMIT;  -- succeeds

-- Session B
COMMIT;  -- succeeds

Beim Aktualisieren name (einer Spalte, die keine Schlüsselspalte ist), entsteht kein Konflikt, wenn der Fremdschlüssel aktiviert ist. product_id Die referenzierende Zeile kümmert sich nur darum, dass die Schlüsselspalten der referenzierten Zeile gleich bleiben.

Bewährte Methoden mit Fremdschlüsseln in Aurora DSQL