How to maintain cross-table consistency with triggers in PostgreSQL? - sql

Question

Some interdependencies between database tables cannot be (easily) modeled with only foreign keys and check constraints. In my current project, I've begun writing constraint triggers for all these conditions, but it looks like I'm going to end up with hundreds of triggers if I go this route.
My main questions are:
Do the triggers and constraints in the scenario outlined below actually cover all the bases, or is it still possible to add/modify data in such a way that the result would be inconsistent?
Is writing all those triggers really the right way to go? I rarely see constraint triggers in 3rd-party DB schemas. Do other people just trust the application not to mess up?
Minimal example scenario
A central "inventory" table contains all tracked items. Some inventory items are of a specific type with specialized dimensions; these extra dimensions are stored in separate tables ("books", "pictures"). This basic table layout cannot be changed (this is just an example; the actual DB obviously has a lot more tables and columns).
Extra requirements:
(A) Every row in the "inventory" table whose type is "book" must have a matching row in "books" (same goes for "pictures")
(B) Every row in the "books" table must point to a unique row in "inventory" whose type is "book" (same goes for "pictures")
(C) Once inserted, an "inventory" record can never change its type
Complete database contents:
"inventory": id | type | name
----+------+----------------------
a | pic | panda.jpg
b | book | How to do stuff
c | misc | ball of wool
d | book | The life of π
e | pic | Self portrait (1889)
"pictures": inv_id | quality
--------+----------------------------
a | b/w photo?
e | nice, but missing right ear
"books": inv_id | author
--------+--------
b | Hiro P
d | Yann M
Create and populate the schema:
CREATE TABLE inventory (
id CHAR(1) PRIMARY KEY,
type TEXT NOT NULL CHECK (type IN ('pic', 'book', 'misc')),
name TEXT NOT NULL
);
CREATE TABLE pictures (
inv_id CHAR(1) PRIMARY KEY REFERENCES inventory(id) ON UPDATE CASCADE ON DELETE CASCADE,
quality TEXT
);
CREATE TABLE books (
inv_id CHAR(1) PRIMARY KEY REFERENCES inventory(id) ON UPDATE CASCADE ON DELETE CASCADE,
author TEXT
);
INSERT INTO inventory VALUES
('a', 'pic', 'panda.jpg'),
('b', 'book', 'How to do stuff'),
('c', 'misc', 'ball of wool'),
('d', 'book', 'The life of π'),
('e', 'pic', 'Self portrait (1889)');
INSERT INTO pictures VALUES
('a', 'b/w photo?'),
('e', 'nice, but missing right ear');
INSERT INTO books VALUES
('b', 'Hiro P'),
('d', 'Yann M');
Add triggers to maintain cross-table consistency:
-- TRIGGER: if inventory.type is 'book', there must be a corresponding record in
-- "books" (provides A, 1/2)
CREATE FUNCTION trg_inventory_insert_check_details () RETURNS TRIGGER AS $fun$
DECLARE
type_table_map HSTORE := hstore(ARRAY[
['book', 'books'],
['pic', 'pictures'] -- etc...
]);
details_table TEXT;
num_details INT;
BEGIN
IF type_table_map ? NEW.type THEN
details_table := type_table_map->(NEW.type);
EXECUTE 'SELECT count(*) FROM ' || details_table::REGCLASS || ' WHERE inv_id = $1'
INTO num_details
USING NEW.id;
IF num_details != 1 THEN
RAISE EXCEPTION 'A new "%"-type inventory record also needs a record in "%".',
NEW.type, details_table;
END IF;
END IF;
RETURN NULL;
END;
$fun$ LANGUAGE plpgsql;
CREATE CONSTRAINT TRIGGER insert_may_require_details
AFTER INSERT ON inventory
DEFERRABLE INITIALLY DEFERRED
FOR EACH ROW EXECUTE PROCEDURE trg_inventory_insert_check_details();
-- TRIGGER: when deleting details, parent must be gone, too (provides A, 2/2)
CREATE FUNCTION trg_inv_details_delete () RETURNS TRIGGER AS $fun$
BEGIN
IF EXISTS(SELECT 1 FROM inventory WHERE id = OLD.inv_id) THEN
RAISE EXCEPTION 'Cannot delete "%" record without deleting inventory record (id=%).',
TG_TABLE_NAME, OLD.inv_id;
END IF;
RETURN NULL;
END;
$fun$ LANGUAGE plpgsql;
CREATE CONSTRAINT TRIGGER delete_parent_too
AFTER DELETE ON books
DEFERRABLE INITIALLY DEFERRED
FOR EACH ROW EXECUTE PROCEDURE trg_inv_details_delete();
CREATE CONSTRAINT TRIGGER delete_parent_too
AFTER DELETE ON pictures
DEFERRABLE INITIALLY DEFERRED
FOR EACH ROW EXECUTE PROCEDURE trg_inv_details_delete();
-- TRIGGER: details records must point to the correct inventory type (provides B)
CREATE FUNCTION trg_inv_details_check_parent_type () RETURNS TRIGGER AS $fun$
DECLARE
table_type_map HSTORE := hstore(ARRAY[
['books', 'book'],
['pictures', 'pic'] -- etc...
]);
required_type TEXT;
p_type TEXT;
BEGIN
required_type := table_type_map->(TG_TABLE_NAME);
SELECT type INTO p_type FROM inventory WHERE id = NEW.inv_id;
IF p_type != required_type THEN
RAISE EXCEPTION '%.inv_id (%) must point to an inventory item with type="%".',
TG_TABLE_NAME, NEW.inv_id, required_type;
END IF;
RETURN NULL;
END;
$fun$ LANGUAGE plpgsql;
CREATE CONSTRAINT TRIGGER check_parent_inv_type
AFTER INSERT OR UPDATE ON books
DEFERRABLE INITIALLY DEFERRED
FOR EACH ROW EXECUTE PROCEDURE trg_inv_details_check_parent_type();
CREATE CONSTRAINT TRIGGER check_parent_inv_type
AFTER INSERT OR UPDATE ON pictures
DEFERRABLE INITIALLY DEFERRED
FOR EACH ROW EXECUTE PROCEDURE trg_inv_details_check_parent_type();
-- TRIGGER: value of inventory.type cannot be changed (provides C)
CREATE FUNCTION trg_fixed_cols () RETURNS TRIGGER AS $fun$
DECLARE
old_rec HSTORE := hstore(OLD);
new_rec HSTORE := hstore(NEW);
col TEXT;
BEGIN
FOREACH col IN ARRAY TG_ARGV LOOP
IF NOT (old_rec ? col) THEN
RAISE EXCEPTION 'Column "%.%" does not exist.', TG_TABLE_NAME, col;
ELSIF (old_rec->col) != (new_rec->col) THEN
RAISE EXCEPTION 'Column "%.%" cannot be modified.', TG_TABLE_NAME, col;
END IF;
END LOOP;
RETURN NULL;
END;
$fun$ LANGUAGE plpgsql;
CREATE CONSTRAINT TRIGGER fixed_cols
AFTER UPDATE ON inventory
DEFERRABLE INITIALLY DEFERRED
FOR EACH ROW EXECUTE PROCEDURE trg_fixed_cols('type');

Answer 1

Zilk, the problem here is that you start out by saying that the schema cannot be modified. The reason you are needing to write this trigger spaghetti code is because the business logic and the design of your schema do not agree. For example, the trg_inv_details_delete is screaming at me as just an attempt to reinvent foreign key referential integrity—something that a DBMS like Postgres does for you.
This is actually a pretty typical subclass/superclass hierarchy problem that needs to be addressed in the design phase of the database. The details of the actual miniworld you are trying to represent is going to dictate how you would model this. From that knowledge would come an enhanced ERD, and then you would translate this conceptual model into a logical schema.
In this specific example, the superclass is Inventory and the subclasses are Books and Pictures. The subclasses form a partial/incomplete disjoint union with the superclass. I would go through the following references as this is a somewhat complex topic to describe here. Essentially, careful design and use of composite primary keys that base their foreign key on the superclass's key will take care of (B), and the presence of the Type attribute in Inventory would be unnecessary, thereby taking care of (A).
So your schema definition only needs a small change, which is to remove the Type attribute as it's redundant and would require triggers to keep the data aligned:
CREATE TABLE inventory (
id CHAR(1) PRIMARY KEY,
name TEXT NOT NULL
);
CREATE TABLE pictures (
inv_id CHAR(1) PRIMARY KEY REFERENCES inventory(id) ON UPDATE CASCADE ON DELETE CASCADE,
quality TEXT
);
CREATE TABLE books (
inv_id CHAR(1) PRIMARY KEY REFERENCES inventory(id) ON UPDATE CASCADE ON DELETE CASCADE,
author TEXT
);
Now, by nature of the schema design, there is no way to have an inventory item be considered a "book," for example, and yet not have the book attributes, so there is no need to have a trigger for that.
If you want to select all pictures and their picture-specific attributes:
SELECT id, name, quality
FROM inventory, pictures
WHERE id = inv_id;
If you want to select all pictures or misc items:
SELECT id, name
FROM inventory
WHERE id NOT IN (SELECT inv_id FROM books);
As far as requirement (C), never allowing an update on an attribute, that's kind of a strange one. This may actually be best done using permissions or something at the application level, as I can't see a scenario where you would want to make it impossible to fix a mistake.
See more on this:
Good Blog Post
Elmasri Chapter 8 Slides
Elmasri Chapter 9 Slides- Start reading on slide 17