Question

Assume that there are two tables in a database. First one is X, second one is Y. Y table has a foreignkey on X table. So, if there is a record on Y table, it’s foreignkey related column value must exist on X table. This is the default behavior.

   X         Y
-------   -------
  ID        ID
            XID <--- Foreignkey to X table.

Now, for all records in X table i want to guarantee that there must be at least one record on Y table. If there isn’t, it should add one automatically. How can i do this?

Answer 1

There are two different issues here.

1. Managing declarative constraints.
2. Managing inserts, updates, and deletes.

The “normal” way to guarantee a row exists in y for every row in x is to include foreign keys in both tables. Each table references the other.

create table x (
  x_id integer primary key,
  y_id integer not null
);

create table y (
  y_id integer primary key,
  x_id integer not null references x (x_id)
);

alter table x
add constraint one_to_one
foreign key (y_id)
  references y (y_id) deferrable initially deferred;

begin transaction;
insert into x values (1, 100);
insert into y values (100, 1);
commit;

Although this guarantees that every “x” has a “y”, so to speak, it doesn’t guarantee that every “x” has a different “y”, or that every “x” has its own “y”. I’m not sure whether that’s your requirement.

This isn’t quite what you’re looking for, because you have a 1:N relationship between your two tables. You could make it work, but I think you’d have to write a trigger to manage changes to table “y”. For example, if the user deletes from “y” the row that “x” holds a foreign key reference to, you’d need to update “x” to reference a different row in “y”.

But this leads to the second issue: managing inserts, updates, and deletes. There are several ways to do that.

• The client is responsible for providing all the statements necessary to keep the database consistent. (With the possible exception of that foreign key problem above, which might better be handled in a trigger on “y”.)
• Clients have no direct access to base tables. All changes are through stored procedures.
• Clients have no direct access to base tables. All changes are through updatable views.

Stored procedures and updatable views can give you some degree of automatically adding a row in “y”, but you have to write procedural code to do it.