实体框架/SQL Server 许多外键
我试图在使用实体框架和 SQL Server 时决定表设计。
我有一个与许多其他实体（大约 15 个）相关的实体（地址）。
我可以在数据库中创建 15 个可为空的 FK 列，也可以创建一个未绑定列 (EntityPrimaryKey) 和一个 EntityType 列来跟踪 EntityPrimaryKey 列值的用途。
这两种不同的设计可能会遇到什么问题？大家意见哪个更好？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
始终使用可用于强制引用完整性的真实外键。
这种“一个键和一个列来定义键的类型”一开始听起来像是一个好主意 - 但最终，由于您无法建立任何引用完整性，所以它确实毫无意义。
随着时间的推移，您最终会在所有不再引用的表中出现“僵尸”子行。对我来说，数据的质量和完整性是良好数据库设计的最重要方面 - 始终确保您的数据完整性是铁定的 - 其他任何事情都比这个要求更重要！
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!