views:

93

answers:

3

For example, I have three tables that store different types of users with different data. But now I want to store their contact information. The table that stores their contact info would be suitable for storing data for all of the user tables.

The problem is that I have different or possibly duplicating ID's between the different user tables so it makes it impossible to create a relationship to my contact table. One solution is to create a contact table for each user type, but it seems wasteful since the only difference would be the ID.

Also, I thought of storing the contact ID in the user table but this seems less then ideal as we may not have the users contact info until later, if at all.

Any other options that I'm missing?

+5  A: 

This is what I'd do:

table Users
UserID                 -PK auto number
UserLogin
UserName

table UserSpecialType1
UserSpecialType1ID     -PK auto number
UserID                 -FK
SpecialInfoA
SpecialInfoB

table UserSpecialType2
UserSpecialType2ID     -PK auto number
UserID                 -FK
SpecialInfoC
SpecialInfoD

table UserContactInfo
UserContactInfoID      -PK auto number
UserID                 -FK
EmailAddress
PhoneNumber
Address
KM
I almost typed this same answer. The important thing that needs to be made clear, though, is that UserSpecialType1.UserId is not the existing ID, but is the new auto-numbered id in the table Users. This design creates a new ID system, but it fixes a major deficiency in the original DB design. (And the old IDs can still be used in the legacy code, if it's done properly.)
Jeffrey L Whitledge
this looks to be the best solution given the problem.. thanks!
bender
A: 

You can use a compound key in the Contact table, e.g. UserTypeID, UserId

pjacko
That would allow a primary key, but not a foreign key.
Jeffrey L Whitledge
+1  A: 

Off the top of my head, I would put all of the Users into the same table with a Type differentiator.

TABLE User
Id
Value1
Value2
UserTypeCode

TABLE UserType
TypeCode

TABLE Contact
UserId
ContactInfo

TABLE UserTypeAttribute
UserType
AttributeTypeCode

TABLE AttributeType
AttributeTypeCode

TABLE UserAttributeTypeValue
UserId
AttributeTypeCode
Value
Jacob G
I was thinking the same about the `Type differentiator`, but I'm sure at some point, some user would want to be two types and this would cause problems with the model. Where I work, users always come up with crazy things like this to break things!
KM
Always very likely to happen. I'd split to a User/Type join table in that scenario. The reason I don't like the unique table per user type model is that, as a developer, I'm querying n-tables every time I want a user if I only have an Id.
Jacob G
based on the context of the query, you might not need to query each. When working on the Farm screen, you query the special FarmUser table, but on the Factory screen you query the FactoryUser table. Processing generic screens you use just the User table
KM
this is an interesting take as well... I guess it comes down to matching how much flexibility you think you will need which isn't always easy to know.
bender