绕过 Access 中的 32-relationship-per-table 限制答案

【问题标题】：Getting around the 32-relationship-per-table limit in Access绕过 Access 中的 32-relationship-per-table 限制
【发布时间】：2009-07-20 15:54:46
【问题描述】：

我正在尝试使用大量表和强制关系构建用于库存控制的数据库，但我刚刚遇到了 Access 表的 32 个关系（索引）限制（使用 Access 2007）。

澄清一下：问题不在于Employees 表有32 个显式索引。相反，问题在于 Employee 表可以在 FOREIGN KEY 约束中被引用的次数的限制。例如：

CREATE TABLE Employees (employee_number INTEGER NOT NULL UNIQUE)
;
CREATE TABLE Table01 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
;
CREATE TABLE Table02 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
;
CREATE TABLE Table03 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
;

...

CREATE TABLE Table30 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
;
CREATE TABLE Table31 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
;
CREATE TABLE Table32 (employee_number INTEGER NOT NULL REFERENCES Employees (employee_number))
;

上面最后一行抛出异常，“无法创建索引；定义了太多索引。

我有什么办法可以解决这个限制？

我听说创建具有 1:1 关系的重复表是一种方法。我是数据库设计的新手，所以如果我错了，请纠正我；但是给定一个具有 31 个索引的表Employees，我将创建一个表Employees2（带有一个字段？），它与Employees 有1：1 的关系，并且与EmployeeID 是外键的任何剩余关系的关系到这个新表。确保第二个表与第一个表一起填充的最佳方法是什么？

还有其他方法吗？

由于缺乏可用信息，这似乎是一个设计合理的数据库的罕见问题，或者解决方案是常识。原谅菜鸟！

更新：立即达成共识是我的设计很无聊或过于雄心勃勃。很可能就是这种情况。但是，我宁愿在一个单独的问题中进行一般设计讨论，所以为了争论，有人可以回答这个问题吗？如果答案只是“永远不要那样做”，我将不得不接受它。

【问题讨论】：

我想你会发现你的整体设计是错误的。否则无法满足此特定限制。
“整体设计有问题”是错误的。我有很多系统遇到过这个问题。
@Tony：啊！感谢您的洞察力。但是我必须指出，我们的询问者说他是“数据库设计新手”......
我从未遇到过类似的情况。我不得不认为设计是非规范化的，例如，重复字段强制执行 RI。
还有一点：关系和索引是两个正交但相关的主题。只能在索引字段之间定义关系，但您可以在未定义 RI 的字段上创建索引。我建议尝试使用 Tony 的实用程序来查看是否有要消除的重复索引。如果您使用 Access 默认值运行，您可能确实有重复的索引（例如，因为表设计器向 ID 字段添加索引，或者因为当您添加与您手动创建的索引重叠的关系时创建的隐藏索引)。

标签： ms-access database-design schema

【解决方案1】：

我的应用程序多次遇到此限制。我可以向其他海报保证我的应用程序设计得非常好。

一个问题是，Access 由于在主索引属性框上不可见但可通过 DAO 集合访问的关系和查找字段而创建索引。这些索引通常也是您创建的索引的重复索引。

我有一个工具，其中包含您导入到您的 BE MDB 中的几个表单，它允许您删除重复的索引。由于我尚未在我的网站上提供此功能，请给我发电子邮件。

【讨论】：

您是否因为隐藏和自动创建的索引而遇到问题？也就是说，您是否曾经遇到过仅使用您打算添加的索引的情况？
大卫，我不确定我是否理解你的问题。每当我遇到这个问题时，都会在幕后创建索引 Access 和我创建的索引。所以我删除了我创建的索引，这些索引让我解决了这个问题。虽然在一个特定的应用程序中这还不够。
在 ANSI-92 查询模式中使用 SQL DLL 的一个优点是您可以在 FOREIGN KEY 声明中使用关键字 NO INDEX 来防止创建隐式索引。现在这让你们都变成了 SQL DDL 狂热分子，对吧？ ;)
但是您为什么要这样做？出于性能目的，您希望在外键上建立索引的可能性非常高。
几句话和你评论的语气听起来很讽刺。

【解决方案2】：

我建议不要定义所有关系/索引来实现 1:1 关系来解决它。这两种解决方案都不是最优的，但后者会产生更高的维护负担和数据异常的可能性。

我不会像其他一些设计那样迅速地谴责这个设计，但它确实让我很感兴趣。你能列出雇员表的外键字段吗？很有可能进行一些规范化，也许 SO 上的一些聪明人可以提出一些设计建议来解决这个问题。

【讨论】：

我对这个计划也有同样的兴趣。我仍然认为一个新的帖子是合适的

【解决方案3】：

我很难相信一个 Employee 表需要 32 个索引；如果确实如此，您应该考虑至少迁移到 SQL Express。

【讨论】：

或其他任何非 Access
我同意 ocdecio 的观点，拥有一个需要 32 个关系的员工表似乎很奇怪，但是我们不知道您的要求。 +1 用于迁移到 SQLServer，我相信您可以将 Access 前端链接到 SqlServer 后端（但从未尝试过）
@Smandoli SQL Server 显然更健壮，更适合大型数据库。我敢肯定有许多更好的选择，但问题仍然存在：我将如何绕过访问限制？请参阅我的问题的更新。如果这不是一个有效的问题，我可以接受。
我建议 32 个索引更可能代表设计错误而不是正确的实现，并且未能纠正设计错误并迁移到支持更多索引的数据库只会加剧原始设计中的问题。
@rmeador：平台抨击并不能解决这个人的问题。

【解决方案4】：

...我会创建一个表员工 2（一个字段？） 1:1 与员工的关系和与这个新表的关系从任何剩余的关系，其中 EmployeeID 是一个外键。

这是可行的。大概您的主表可能有一个自动编号字段作为主键，或者您生成一个索引号。您的 Employees2 表显然必须响应这一点。

什么是确保第二个表在旁边填充第一个？

这在一定程度上取决于您添加记录的方式。但总的来说，您当然必须遵守诚信规则。这通常归结为以正确的顺序附加到表中，并确保在尝试在其他地方添加相关记录之前保存每条记录。

【讨论】：

很好，我主要担心的是我解决这个问题的方法是有效的（误导或否）。我应该能够设置一个表单来将新记录添加到员工并将其相应 ID 的副本添加到第二个表。
好。我相信它会顺利进行。如果您想发布基本表格方案（“您将如何处理......”）并充实细节，我会对您获得的内容非常感兴趣。