假设我有一个用户表和角色表
我有两种角色类型，员工和雇主
在用户表内，我有以下列
用户ID
姓
名字
RoleId（外键 - 一对多）
雇主可以拥有相关公司，而员工可以拥有相关的简历
因此，最好定义两个与User表具有一对一关系的附加表（Employee，Employer），并在其中包含Company / CV外键，或者更好地定义User表，如此
用户ID
姓
名字
CompanyId - 为员工留空（允许为空）
CVId - 为雇主留空（允许为空）
角色ID
我正在考虑添加两个额外的表（员工和雇主），这似乎更合理，但那么Role表的用途是什么，并且留下空白似乎是一种可行的方法，只是不显示添加/编辑新员工/雇主时的字段...但我不确定这样做是否存在任何安全问题/缺点，这就是为什么我想向您寻求建议
答案 0 :(得分：2)
这两种方法都是在数据模型上实现继承的常用策略，第一种方法称为TPT（每种类型的表），第二种方法称为TPH（每层次表）。
这是一篇很棒的文章，描述了＆amp;比较两种策略http://blogs.msdn.com/b/alexj/archive/2009/04/15/tip-12-choosing-an-inheritance-strategy.aspx
哪种策略最好？特技提问！孤立你的 要求没有“最佳”策略。以下是一些事情 您可能需要在做出决定时考虑：
- 性能：每个层次结构表通常表现更好，因为不需要连接，所有内容都在一个表中。该 一旦继承层次结构，决策变得更加明确 变得宽阔或深沉。
- 灵活性：每种类型的表通常由ISV使用，因为它允许自定义而无需修改“基础”表。即新的亚型 可以通过为这些子类型创建新表来添加。
- 数据库验证：TPH要求派生类型中的列在数据库中为NULLABLE，以便可以存储其他派生类型 同桌。因此，可以在中创建行 根据概念模型无效的表。即该 column是NULLABLE但是特定列的组合 NULL和特定的鉴别器或类型无效。这意味着 数据库不再为您强制执行概念模型。 如果对数据库的所有访问都是通过EF进行的，那么这很好 使用其他任何东西，你可以得到'脏'数据。
- 美学：这个是完全主观的，但TPT对我来说更像是面向对象:)。
- 存储空间：如果您的继承层次结构有很多类型，那么使用TPH将导致大量空单元格。如果你的数据库 可以很好地处理'稀疏'列，这可能不是一个真正的问题。
正如你所知，一旦你知道它是什么，你应该寻找它 选择策略是一项非常容易的任务。大部分时间都是 推荐是TPH，因为通常表现胜过其他 关注。但每种情况都不同，关键在于 准确理解你的价值，然后做出决定 相应