在访问中绕过32关系表的限制
在访问中绕过32关系表的限制
提问于 2009-07-16 15:55:17
我试图使用大量的表和强制关系来构建库存控制数据库，我刚刚遇到了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个索引，我会创建一个表Employees2(有一个字段吗？)使用1:1与员工的关系和与此新表的关系，这些关系来自于EmployeeID是外键的任何剩余关系。确保第二个表与第一个表一起填充的最佳方法是什么？
还有别的办法吗？
基于缺乏可用的信息，这似乎是一个罕见的问题，一个适当设计的数据库，或解决方案是常识。原谅那个菜鸟！
更新：当前的共识是，我的设计过于单调或过于雄心勃勃。情况很可能是这样的。然而，我宁愿在一个单独的问题中进行一般性的设计讨论，所以为了争论，有人能回答这个问题吗？如果答案仅仅是“永远不要那样做”，我将不得不接受。
Stack Overflow用户
发布于 2009-07-19 15:50:05
我建议不要定义所有的关系/索引来实现1:1的关系来绕过它。这两种解决方案都不是最优的，但后者将造成更高的维护负担和数据异常的可能性。
我不会像其他人那样快速地谴责这个设计，但它确实引起了我的兴趣。可以列出员工表中的外键字段吗？有一个很好的可能性，一些规范化是适当的，也许一些聪明的人，所以可以提出一些设计建议，以解决这个问题。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/1138580
复制相关文章
相似问题
腾讯云开发者
