Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m trying to decide on table design when working with Entity Framework and SQL Server.
I have a single entity (Address) that is related to many other entities (about 15).
I can either create 15 nullable FK columns in the DB or create a single unbound column (EntityPrimaryKey) and an EntityType column to track what the EntityPrimaryKey column value is for.
What issues might I have with these two different designs? Opinions on which is better?
Always use the real foreign keys that can be used to enforce referential integrity.
This “one key and a column to define the type of the key” might sound like a good idea at first – but ultimately, since you cannot establish any referential integrity, it’s really quite pointless.
Over time, you’ll end up with “zombie” child rows in all the tables that aren’t referenced anymore. And the quality and integrity of the data is the most important aspect of a good database design to me – always make sure your data integrity is iron-clad – anything else takes a back seat to this requirement!