我正在制作一个新的实体框架模型，以更清洁，更准确的方式存储我们的数据。我们目前的数据库（在Access中）充满了重复和不可靠的数据，并且没有由数据库专家规划，因此通常完全缺少主键。它也非常大，因此查询需要很长时间（即使使用索引。）
在新的数据库模型中，我希望它允许一个部门的员工快速输入，以及为其他人快速选择。我们有超过一百万条记录的表格，更不用说审计表了，当然这些表格要大得多。
我的模型有一个公司表，其中companyID作为主键，contactID作为主键的联系表，然后是一个名为CompanyContact的关联表，它将companyID和contactID都设置为主键。然后，我需要将其他表与此关联表相关联。例如，如果我想存储员工和联系人之间的交互（他们可能同时为多家公司工作），我可以为这个交互表设置主键为companyID，contactID和EmployeeID，但我会有3个主键。 （我在数据库中有很多其他关于这个问题的场景。）
我记得读（在某处......）给表提供超过1个主键会减慢查询速度。他们建议给CompanyContact表（根据上面的例子）提供一个id字段作为主键，以及2个外键（CompanyID和ContactID），然后将交互表与该id字段相关联。我更习惯按照他们推荐的方式进行操作，但是已经看到从外键中创建多个主键可以在根目录停止复制，而无需在任何地方编写代码。
有人能告诉我多少主要字段会减慢查询速度以及最推荐的方法是什么？提前谢谢！
答案 0 :(得分：1)
您正在考虑复合主键与代理键。关于这个话题有很多争论。
复合键具有使该行唯一的所有字段，如果它们都是int或bigint，则可以正常工作，如果它们更大（即varchar）字段，则不能正常工作。密钥长度也必须保持不变。
代理键方法可能会有一个自动增量整数，关键字段会有一个唯一的索引，以防止重复。
对于为多家公司工作的员工，最好将公司A的员工视为与公司B的同一员工分开的实体。如果不是，我会考虑更复杂的设计。人员表，员工表，同一个人记录可能与许多员工记录有关。每个员工根据就业“合同”记录与公司联系。
我会对联系人做同样的事情。通过这种方式，您的通信设计可以简化和简洁，同时仍然可以从多个公司（供应商，客户等）识别相同“人”的查询
通过这种方式，您提到的表只需要employeeid和contactid作为密钥。否则你需要contactcompany和employeecompany？
根据我如何阅读您的请求，提出一些想法。关于高级实体设计的课程或好书将真正有助于确保您从一开始就获得最佳设计，并且从长远来看可以为您节省大量时间，以便随时发现和重构。