我必须实现一个测试平台。我的数据库需要以下表:Students, Teachers, Admins, Personnel等。我想知道在每个表中都有FirstName和LastName是否更有效，或者有另一个表Persons，并且每个其他表都与PersonID链接到这个表。
就我个人而言，我喜欢这种方式，尽管实现起来更棘手，因为我认为它更清晰，特别是如果你从面向对象的角度来看它。这会给数据库增加不必要的开销吗?
不知道它是否有助于提及我想使用SQL Server和ADO。. NET实体框架。
正如您明确提到的OO和您正在使用的EntityFramework一样，也许值得从框架的工作方式来解决问题，而不仅仅是构建数据库结构，然后尝试对其建模?
实体框架代码优先继承:每个层次表和每个类型表是一个很好的介绍各种策略，你可以从中选择。
关于给数据库增加不必要的开销的注释——我现在还不担心。EF通常是为了更快地构建产品，因为它必须处理更一般的情况，所以并不总是产生最有效的SQL。如果在您的应用程序构建、工作和正确之后性能出现问题，那么您可以重新访问并修复最低效的部分。
如果上面提到的表中有重叠的人，那么是的，你应该把他们分开到一个Persons表中。
如果您只跟踪每个Person的角色(即Student与Teacher等)，那么您可能会考虑只使用以下三个表:Persons, Roles和桥接表PersonRoles。
另一方面，如果每个角色都有自己的唯一字段，那么您应该继续这样做，并使用PersonID的外键将每个表分开。
如果这些entities(即学生，教师，管理员和人员)的attributes(即名，姓，性别等)完全相同，那么您可以为所有添加PersonType或Role属性的实体制作一个表，以区分每个人的角色。但是，如果实体有很多不同的属性，那么最好创建单独的表，否则就会出现normalization问题。
是的，这是一种非常糟糕的构建DB的方式。数据库结构应基于规范化设计。
请核对正规化表格。
你应该尽量避免重复的数据，否则查询会变慢。
主要问题是当你试图获取与一个或两个以上的表相关联的数据时