我正在研究一个有很多多对多关系的数据库模型。
在我的方案中，有一组6个表（让我们说T1，T1 ... T6）和另一组8个表（让他们说S1，S2 ...... S8）。假设每个表（T1，T1 ... T6，S1，S2 ...... S8）具有PK。 第一组的每个表都与第二组的每个表相关联，我需要存储有关关系的信息，就像您在这个简单示例中看到的那样： http://en.wikipedia.org/wiki/Junction_table
如何应对这种情况？
One True Lookup Table（OTLT）是否优于6 x 8关联表解决方案？ 是否存在更好的解决方案？
提前感谢您的回复。
----- --- EDIT
我上传了一些图片以解决问题：
问题：http://i.stack.imgur.com/ltCZx.png
我知道OTLT方法意味着性能较低，但另一方面是建模问题的最快方法。 Explosion Pills建议我将所有T1，... T6表合并成一个大表。由于T1 ... T6与模式的其他（未提及）表有其他关系，因此该解决方案不可能（至少不在该模型中）。
答案 0 :(得分：0)
你可以在这里看到我的OTLT讨论：
http://granadacoder.wordpress.com/2009/05/06/one-true-lookup-table-discussion/
但基本上，对于OTLT，你冒着将错误数据放入表格的风险。
假设您有一个Employee表，其中一个“查找”是EmployeeStatus。例如，Employee.EmpStatus列。
您的OTLT表有多个员工状态.....但它有很多其他的东西。就像“OrderStatus”一样，它与Employee-Status没有任何关系。
那你做什么？
上面的链接显示代码使用check-constraint确保只将OTLT中的有效值放入Employee.EmpStatus列。
然而，虽然它可以保护数据的完整性，但却需要付出代价。每个插入都必须进行检查约束检查（duh）........
所以我试着找到力量的平衡。如果Lookup非常通用，我把它放在OTLT中。一旦它做了任何事情，我就移动它。
这是我的另一招。 在高并发数据库上，我将在DEV和QA中使用check-constraint。但是在生产中我会禁用它，至少只要没有任何问题。
答案 1 :(得分：0)
正如Joe Celko解释here，“一个真实的查找表（OTLT）是一个不断出现的噩梦”：糟糕的数据，大数据，锁定，错误的查询计划和性能问题，你的瓶颈应用程序，不可读的查询...
也许你可以重新设计你的表，以便它们只是更通用一些并分享一些常见信息，而不是在OTLT中结束？
