Sie brauchen überhaupt keine Trigger oder PL / pgSQL.
Sie haben nicht einmal müssen DEFERRABLE Einschränkungen.
Und Sie müssen keine Informationen redundant speichern.
Fügen Sie die ID der aktiven E-Mail in die usersTabelle ein, wodurch sich gegenseitige Verweise ergeben. Man könnte meinen, wir brauchen eine DEFERRABLEEinschränkung, um das Henne-Ei-Problem des Einfügens eines Benutzers und seiner aktiven E-Mail zu lösen, aber mit datenmodifizierenden CTEs brauchen wir das nicht einmal.
Dies erzwingt zu jeder Zeit genau eine aktive E-Mail pro Benutzer :
CREATE TABLE users (
user_id serial PRIMARY KEY
, username text NOT NULL
, email_id int NOT NULL -- FK to active email, constraint added below
);
CREATE TABLE email (
email_id serial PRIMARY KEY
, user_id int NOT NULL REFERENCES users ON DELETE CASCADE ON UPDATE CASCADE
, email text NOT NULL
, CONSTRAINT email_fk_uni UNIQUE(user_id, email_id) -- for FK constraint below
);
ALTER TABLE users ADD CONSTRAINT active_email_fkey
FOREIGN KEY (user_id, email_id) REFERENCES email(user_id, email_id);
Entfernen Sie die NOT NULLEinschränkung von users.email_id, um es zu "höchstens einer aktiven E-Mail" zu machen. (Sie können immer noch mehrere E-Mails pro Benutzer speichern, aber keine davon ist "aktiv".)
Sie können machen active_email_fkey DEFERRABLEmehr Spielraum ermöglichen (insert Benutzer und E - Mail in separaten Befehlen der gleichen Transaktion), aber das ist nicht notwendig .
Ich habe user_iddie UNIQUEEinschränkung email_fk_unizur Optimierung der Indexabdeckung an erster Stelle gestellt . Einzelheiten:
Optionale Ansicht:
CREATE VIEW user_with_active_email AS
SELECT * FROM users JOIN email USING (user_id, email_id);
So fügen Sie neue Benutzer mit einer aktiven E-Mail ein (nach Bedarf):
WITH new_data(username, email) AS (
VALUES
('usr1', 'abc@d.com') -- new users with *1* active email
, ('usr2', 'def3@d.com')
, ('usr3', 'ghi1@d.com')
)
, u AS (
INSERT INTO users(username, email_id)
SELECT n.username, nextval('email_email_id_seq'::regclass)
FROM new_data n
RETURNING *
)
INSERT INTO email(email_id, user_id, email)
SELECT u.email_id, u.user_id, n.email
FROM u
JOIN new_data n USING (username);
Die besondere Schwierigkeit besteht darin, dass wir weder haben user_idnoch email_idanfangen. Beides sind die Seriennummern der jeweiligen SEQUENCE. Es kann nicht mit einer einzigen RETURNINGKlausel gelöst werden (ein weiteres Henne-Ei-Problem). Die Lösung ist nextval()wie in der verknüpften Antwort unten ausführlich erläutert .
Wenn Sie den Namen der angehängten Sequenz für die Spalte nicht kennen , können Sie Folgendes ersetzen:serialemail.email_id
nextval('email_email_id_seq'::regclass)
mit
nextval(pg_get_serial_sequence('email', 'email_id'))
So fügen Sie eine neue "aktive" E-Mail hinzu:
WITH e AS (
INSERT INTO email (user_id, email)
VALUES (3, 'new_active@d.com')
RETURNING *
)
UPDATE users u
SET email_id = e.email_id
FROM e
WHERE u.user_id = e.user_id;
SQL-Geige.
Sie können die SQL-Befehle in serverseitigen Funktionen einkapseln, wenn ein einfacher ORM nicht klug genug ist, um damit umzugehen.
Eng verwandt mit ausführlichen Erklärungen:
Auch verwandt:
Über DEFERRABLEEinschränkungen:
Über nextval()und pg_get_serial_sequence():