What is the best practice for a database table with a two-column primary key where one of the columns is optional?

Question

At work, were reviewing a table that consists of three columns:

1. Row Id (Not Null, Integer)
2. Context Id (Not Null, Integer)
3. Value (Not Null, Variable Character)

The total number of rows is small (less than 100). The Context Id is currently set to 0 if there is no Context Id. Context Id is optional.

The primary key is (Row Id,Context Id)

In this situation, there were two choices proposed:

1. Keep it as it is

2. Divide the table into two tables. One table when Context Id is 0 (Row Id, Value) and one table when Context Id has a value (Row Id, Context Id, Value).

If there are a large number of rows, then I agree with the decision to split up the table. If there are a small number of rows, dividing up the table seems like overkill.

I would be very interested what folks recommend in this situation? Is it better to always divide up the single table into two tables?

Thanks,

-Larry

Answer 1

First, if this is the entity-attribute-value antipattern, avoid that. The rest of this answer assumes that it isn't.

When deciding if you are giong to model something generically (single table) or specifically (two tables) you need to consider if your code will be able to process things generically or need special cases.

Are Special Cases Required?

Will your code give special treatment to a ContextId of 0? For example, might you run a select WHERE ContextId=0 and then go on and look at a different context in a generic manner? Is there special logic that you would only do with ContextId=0? Would you feel the need for a special constant representing this contextId in your code? Would you this constant appear in some if statements?

If the answers to these questions are generally yes, then create the separate table. You will not gain from putting this stuff in a single table if you treat it differently anyway.

It's my guess that this is the case based on your question.

Or is it all Generic?

If the ContextId of zero is treated just like all the other context ids throughout your code, then by all means put it in the same table as the others.

Tradeoffs

If things are not so clear-cut, you have a tradeoff decision to make. You would need to make this based on how much of your usage of this information is generic and how much is specific. I would be biased towards creating two tables.

Answer 2

There is not enough information to decide but:
In the perspective of database design, attending to minimum side-effect changes, I will prefer adding a new column to the table, called ID and setting it as the Primary Key of the table, having a new unique key on (Row Id + Context Id) columns.
The logic behind (Row Id + Context id) is your applications logic and application logic is bind to changes.
Its recommended to use primary key of your tables being separated of business identifiers and logic. Any field is showed to the end user, is at risk of being requested to change, making maintenance and develop hard.
Hope be helpful.