Relational table that is constrained to a subset of its referee - sql

Question

Say I have the following table:
create table foo (
id integer primary key,
mode integer not null check (mode in (1, 2))
);
Now I want to store additional information about records from this table, but only those that have, say, mode = 1. The way I thought I could do this is as follows:
create table foo_bar (
id integer primary key,
foo_id integer,
_mode integer not null default (1) check (_mode = 1),
foreign key (foo_id, _mode) references foo(id, mode)
);
That is, we have a dummy column in foo_bar that is forcibly always equal to 1 and include that in the foreign key constraint with foo.
However, not only does this not work (with pragma foreign_keys = ON;), but that foreign key constraint can be violated when you insert multiple values into foo!
sqlite> insert into foo(mode) values (1);
sqlite> insert into foo(mode) values (2);
sqlite> select * from foo;
1|1
2|2
sqlite> insert into foo_bar(foo_id) values (1);
Error: foreign key mismatch - "foo_bar" referencing "foo"
sqlite> insert into foo_bar(foo_id) values (2);
Error: foreign key mismatch - "foo_bar" referencing "foo"
sqlite> insert into foo(mode) values (1), (2);
Error: foreign key mismatch - "foo_bar" referencing "foo"
Is this a bug in SQLite (I'm using 3.17, it it matters), or am I doing it wrong?
An alternative option, without the foreign key, might be to use a trigger:
create trigger bad_mode
before insert on foo_bar when (select mode from foo where id = NEW.foo_id) <> 1
begin
select raise(fail, "Invalid mode");
end;
...but this seems a bit gross!

Answer 1

The documentation says:
Usually, the parent key of a foreign key constraint is the primary key of the parent table. If they are not the primary key, then the parent key columns must be collectively subject to a UNIQUE constraint or have a UNIQUE index.
That missing UNIQUE constraint is what causes the "foreign key mismatch" error.
It is not possible to use a subquery in a CHECK constraint, so the only way to enforce the mode = 1 constraint is to make it part of the foreign key constraint, or to use triggers.

Answer 2

I think you could improve the design, and no constraints other than FK are needed:
First of all foo.mode could be a foreign key to another table, say modes, no need to use a check constraint. You would store the values 1 and 2 there.
A second table, say bar_modes, could have a field mode, a FK to modes. You would store the value 1 in this table.
Finally, foo_bar.foo_id would be FK to foo.id, and foo_bar.mode a FK to bar_modes.mode.
Let me know what you think!
SQL Server example for M = 3, N = 5
create table modes (
id int primary key
)
create table foo (
id int primary key,
mode int not null foreign key references modes(id)
);
create table bar_modes (
id int primary key foreign key references modes(id)
)
create table foo_bar (
id int primary key,
foo_id int foreign key references foo(id),
other_data varchar(20)
)
insert modes (id) values(1)
insert modes (id) values(2)
insert modes (id) values(3)
insert modes (id) values(4)
insert modes (id) values(5)
insert bar_modes (id) values (1)
insert bar_modes (id) values (2)
insert bar_modes (id) values (3)
insert foo (id, mode) values (1000, 1)
insert foo (id, mode) values (2000, 2)
insert foo (id, mode) values (2500, 2)
insert foo (id, mode) values (5000, 5)
insert foo_bar (id, foo_id, other_data) values (100, 1000, 'data for foo 1000')
insert foo_bar (id, foo_id, other_data) values (200, 2000, 'data for foo 2000')
insert foo_bar (id, foo_id, other_data) values (250, 2500, 'data for foo 2500')