database design

Question

im creating a database that records details from multiple forms and each form has a status and a revision. I want to create one table that holds all the revision and status data for all the forms however im a little stuck with the design and how i can define the relationships between the forms tables and the 1 revision and status table.

The tables i have are as follows. Ive abbreviated the tables for simplicity

tasks
---------
pk int id


briefs
---------
pk int id

Revisions
---------
fk formId
int status

I want to link the tasks and the briefs table to the revisions table but obviously there will be a conflict with the pk's of the parent tables. Is the best option to use the revisions table like a look up table and store the primary key of the revisions table in the tasks and briefs table.

Thanks in advance

Answer 1

You could do this in two tables, if tasks and briefs only have the id in them and no other columns, or if the columns are identical.

tasks_and_briefs
----------
pk int id
int task_or_brief  (e.g 0 for Task, 1 for Brief) or varchar task_or_brief  (e.g. "Task", "Brief")  or whatever else you wish.

revisions
----------
pk int formId
int id
int status

Answer 2

Option 1 :

Create a Forms table, that is the central source of Form IDs. When inserting into Tasks/Briefs/etc (I assume there may be many more), you first insert into the Forms table, then use that ID as a PK/FK in Tasks or Briefs.

Then you have FormID in Revisions just reference the FormID in Forms.

You'd probably want to record the form type in the Forms table, and possibly enforce that if you've inserted say "1,Task" into Forms, that the only table you can insert 1 into is the Tasks table. There are ways to do that.

You might also want to hide some of these facts behind views/triggers (so you just insert into Tasks, and behind the scenes it does the insert into Forms, etc).

Option 2 :

Create one column per table in the Revisions table. Add a constraint such that exactly one of these columns is not null. This does allow you to use more specific foreign key constraints (unlike option 1, where just because there's a Form ("1,Task") in Forms, you couldn't guarantee there would be a row in the Tasks table). But if you're adding new form types, you have to add more columns to Revisions.

There are some other options, but these are the two that spring to mind.

Answer 3

It sounds like you can treat tasks and briefs as subtypes of the supertype "forms". (I'm using supertype and subtype in their relational database design sense, not in their object-oriented programming sense.)

create table forms (
  form_id integer not null,
  form_type char(1) not null check (form_type in ('T', 'B')),
  other_form_columns char(1),
  primary key (form_id, form_type)
);

create table tasks (
  form_id integer not null,
  form_type char(1) not null default 'T' check (form_type = 'T'),
  other_task_columns char(1),
  primary key (form_id, form_type),
  foreign key (form_id, form_type) references forms (form_id, form_type)
);

create table briefs (
  form_id integer not null,
  form_type char(1) not null default 'B' check (form_type = 'B'),
  other_brief_columns char(1),
  primary key (form_id, form_type),
  foreign key (form_id, form_type) references forms (form_id, form_type)
);

Having done that, you can create a table of revisions that references the primary key in "forms".

create table revisions (
  form_id integer not null,
  form_type char(1) not null,
  revision_num integer not null check (revision_num > 0),
  revision_status varchar(20) not null,
  other_revision_columns char(1),
  primary key (form_id, form_type, revision_num, revision_status),
  foreign key (form_id, form_type) references forms (form_id, form_type)
);

This particular structure assumes that

• you can have more than one status per revision number, and
• revisions of tasks and revisions of briefs mean the same thing.

If task revisions don't mean the same thing as brief revisions, then you need one table for task revisions, and another table for brief revisions. Their primary keys wouldn't reference the supertype table "forms"; they would reference the subtype tables "tasks" and "briefs" instead.