I was asked a very interesting question on Twitter just now:
Can we have “constant” foreign key columns in (PostgreSQL) tables? Luckily, yes, we can. Using a nice standard feature that is “computed columns” or “generated columns”
Sometimes, you cannot completely normalise your schema for whatever reason. There may be a case where you have a table with a composite primary key like this:
CREATE TABLE t1 ( a int, b int, t1 int, PRIMARY KEY (a, b) )
And in a referencing table t2, you will always reference one of the primary key columns by value, say, 1. Of course, you could create a table t2 with a CHECK constraint ensuring b = 1:
CREATE TABLE t2 ( a int, b int NOT NULL DEFAULT 1 CHECK (b = 1), t2 int, FOREIGN KEY (a, b) REFERENCES t1 )
But why not use a generated column instead?
CREATE TABLE t2 ( a int, b int GENERATED ALWAYS AS (1) STORED, t2 int, FOREIGN KEY (a, b) REFERENCES t1 )
In my opinion, this is even more powerful. As of PostgreSQL 12, only STORED is supported (meaning the value is stored on disk), when in this case VIRTUAL would be even better (meaning the value is produced only when reading the row).
Inserting some test data:
INSERT INTO t1 (a, b, t1) VALUES(1, 1, 1), (1, 2, 2), (2, 1, 3); INSERT INTO t2 (a, t2) VALUES (1, 11), (2, 12); SELECT * FROM t1 NATURAL LEFT JOIN t2
Produces the expected result. We can only insert (b = 1) into t2:
a|b|t1|t2| -|-|--|--| 1|1| 1|11| 2|1| 3|12| 1|2| 2| |
A nice trick to keep up one’s sleeve.
Computed or generated columns are available in a variety of RDBMS, including at least:
- SQL Server