Question

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

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

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为外键的任何剩余关系中与该新表的关系。确保第二个表与第一个表一起填充的最佳方法是什么？

还有其他方法吗？

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

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

Answer 1

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

一个问题是Access由于在主索引属性框中无法查看的关系和查找字段而创建索引，但是可以通过DAO集合访问它们。这些索引通常是您创建的索引的重复索引。

我有一个工具，由您导入BE MDB的几种表单组成，允许您删除重复的索引。由于我还没有在我的网站上提供这个，请给我发电子邮件。

Answer 2

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

我不会像其他一些人一样快速地谴责设计，但它确实让我很感兴趣。你能列出作为外键的employee表的字段吗？有一个很好的可能性，一些规范化是有序的，也许一些聪明的人可以提出一些设计建议来解决这个问题。

Answer 3

我很难相信Employee表需要32个索引;如果实际上你应该考虑迁移到至少SQL Express。

Answer 4

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

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

确保这一目标的最佳方式是什么？第二张表填充在旁边第一个？

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

在Access中绕过每个表的32个关系限制

4 个答案: