Should I create separate table or have the information as columns in the same table Sorry for the title but I could not find anything better that could suit my needs. I'm designing the database of a Document Management (Circulation) application. There are two types of documents - A and B. I've created a table one for each. Any document independent from its type has Instructions information that has to be attached to it. Here are the details of the Instrcutions:

Executors (1 to many on another table)
Deadline
Target


I know that there's a one to one relationship between the document types and Instructions, so according to database normalization I should not have a separate table for it. But on the other hand I'll have to include the same columns in two different tables. What do you think?

P.S. I won't be able to create a foreign key constraint between Instructions table and the two other.
If you really want to normalize your design, here is a suggestion to do so. You should be able to create foreign key constraints. This is without the extra Instruction table since all documents will have the instruction details, stored in the Document table:

Executor
----------
ExecutorID


Document
----------
DocumentID
ExecutorID
Deadline
Target
-- other columns, relative to all documents


DocumentA
----------
DocumentID
-- other columns, relative only to documents of type A


DocumentB  
----------
DocumentID 
-- other columns, relative only to documents of type B


and their relationships:

              Executor
                /1
               /
              /
             /0..N 
         Document
         1/    \1
         /      \
        /        \
   0..1/          \0..1
 DocumentA      DocumentB


*Note: the only constraint not shown (and enforced) with the above design is that a document has to be of either A or B type (and not both.) This can be enforced as well, with a somewhat more complex design.