为什么在 SQL 中有一个 1:m 关系的连接表

Question

在以下数据库中第一个 1:m 和第二个 1:m 关系之间拥有联结表有什么好处？

替代文本http://dl.getdropbox.com/u/175564/db/db-simple.png

这本书 Joe Celko 在 SQL 中为 Smarties 提供的树和层次结构 说原因是在 1:m 中具有唯一的关系。例如，下表分别限制用户询问完全相同的问题两次和给出完全相同的答案两次。

第一个 1:m 关系

users-questions
===============
user_id REFERENCES users( user_id )
question_id REFERENCES questions ( question_id )
PK( user_id, question_id)           // User is not allowed to ask same question twice 

第二个1:m关系

questions-answers
=================
question_id REFERENCES questions( question_id)
answer_id REFERENCES answers( aswer_id )
PK( question_id, answer_id )       //  Question is not allowed to have to same answers

这种独特性的好处并不能说服我让我的代码更具挑战性。我不明白为什么我应该限制数据库中具有相同 ID 的问题或答案的可能性，因为我也许可以使用 PHP 来禁止这种情况。

Answer 1

它通常是由于数据的重复。

至于你的推理，是的，你可以在业务层执行，但如果你犯了一个错误，它可能打破代码显著量。你的问题是你的数据模型可能只有几桌。幸运的你。当你的数据模型的增长，如果不能使结构感，你必须把所有的逻辑，以保持在您的GUI层去归一化的表，你可以很容易遇到问题。请注意，这是很难让事情线程安全的为您的SQL数据库的GUI不使用锁定，这将破坏你的表现。

DBMS是非常在处理这些问题非常好。你可以把你的数据模型干净，使用索引为您提供您所需要的速度。你的目标应该是得到它的权利第一，也是唯一denormalise您的表时，你可以看到一个明显需要这样做（性能等）

不管你信不信，有很多情况下具有标准化的数据，使您的生活更轻松，而不是更辛苦，当涉及到你的应用程序。举例来说，如果你有问题和答案一个大表，你必须编写代码来检查它是否是唯一的。如果你有一个主键的表，只要简单的写

insert into table (col1, col2) values (@id, @value) --NOTE: You would probably 
--make the id column an autonumber so you dont have to worry about this

该数据库将阻止你，如果你有一个非唯一值存在，或者如果您将在没有问题的答案插入。所有你需要做的是检查是否插入工作，仅此而已。哪一个你认为是更少的代码？

Answer 2

嗯，唯一关系的事情对我来说似乎毫无意义，可能是因为我习惯了 DBMS，在 DBMS 中您可以定义除主键之外的唯一键。在我的世界里，像这样的映射表是实现多对多关系的方式，而将它们用于一对多关系是疯狂的——我的意思是，如果你这样做，也许你 打算 将关系用作一对多，但实际上您已经 实施的 是多对多的支持。

我不同意您所说的持久层中唯一复合键没有效用的说法，因为您可以在应用程序层中强制执行这一点。持久层唯一性约束有很多难以复制的好处，例如，在 MySQL 中，能够利用 INSERT ... ON DUPLICATE KEY UPDATE.

Answer 3

我同意参加表一一对多在这种情况下似乎并没有增加太多的好处，并作为@chaos说，你实际上最终实现多到很多的支持。但乔·塞科是一个聪明的家伙 - 这真的是确切的答案，他给

其他一个可能的原因上的一对许多实施一个连接表是，它完全从用户的依存分离的问题/答案。

举例来说，假设你加入Dogs表和一个Deities表。我们都知道，狗不能注册为用户，因为他们没有电子邮件地址，因为，这是他们脚下的神不注册为用户。也许狗和神仍提问，虽然，但要做到这一点，你可能想实现一个狗，问表和神灵，问表。在理论上，这是仍有许多一对多的，但实际上，你愿意这样做，你可以有多个一到manys。