Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I have an existing table called Realms. This has the superkey rlmID (just a surrogate key). We are planning to add tables that group realms in some context -- let's just calll them RealmGroups. This will require adding a realmGroupID column to Realms. No problemo.

Not all Realms will be part of RealmGroups, so Realms.realmGroupID would be nullable. In this case, is it better to have a separate table (RealmsRealmGroups) that has (rlmID,realmGroupID)? Since the superkey of Realms and RealmsRealmGroups would be the same, I see no advantage to creating a separate table, but my DBA is suggesting that we should use a separate one for organizational purposes.

Are there any technical or practical reasons to use a separate table to store information for the same superkey?

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

A separate table would give you the flexibility of having realms that are in more than one group. If it makes sense to do that in your business context, or it might be something you would want in the future, then you might want to seriously consider that option. Otherwise, having the Realms.realmGroupID as nullable is simpler and easier to work with.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.