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.