处理这些MySQL数据库关系的最佳方法是什么？

Question

我正在建立一个小网站，让用户将他们最喜欢的书籍推荐给海誓山盟。所以我有两张桌子，书和小组。用户可以在他们的图书馆中拥有0本或更多书籍，并且一本书属于1个或更多组。目前，我的表是这样的：

books table 
|---------|------------|---------------| 
| book_id | book_title | book_owner_id | 
|---------|------------|---------------| 
| 22  | something | 12   | 
|---------|------------|---------------| 
| 23  | something2 | 12   | 
|---------|------------|---------------| 

groups table 
|----------|------------|---------------|---------| 
| group_id | group_name | book_owner_id | book_id | 
|----------|------------|---------------|---------| 
| 231  | random  | 12   | 22  | 
|----------|------------|---------------|---------| 
| 231  | random  | 12   | 23  | 
|----------|------------|---------------|---------| 

正如你所看到的，用户+书籍和书籍+群体之间的relationsships表中定义。我应该在他们自己的表中定义关系吗？事情是这样的：

books table 
|---------|------------| 
| book_id | book_title | 
|---------|------------| 
| 22  | something | 
|---------|------------| 
| 23  | something2 | 
|---------|------------| 

books_users_relationsship table 
|---------|------------|---------| 
| rel_id | user_id | book_id | 
|---------|------------|---------| 
| 1  | 12   | 22 | 
|---------|------------|---------| 
| 2  | 12   | 23 | 
|---------|------------|---------| 

groups table 
|----------|------------| 
| group_id | group_name | 
|----------|------------| 
| 231  | random  | 
|----------|------------| 

groups_books_relationsship table 
|----------|---------| 
| group_id | book_id | 
|----------|---------| 
| 231  | 22  | 
|----------|---------| 
| 231  | 23  | 
|----------|---------| 

感谢您的时间。

Answer 1

带有四个表的第二种形式是正确的。您可以从books_users_relationsship中删除rel_id，因为主键可能与user_id和book_id合成，就像在groups_books_relationsship表中一样。

Answer 2

您不需要“关系表”来支持关系。在数据库中，在子表中实现外键定义了父和子之间的关系。只有当表包含数据或解决多对多关系（并且没有除父项主键之外的数据）时，才需要表。

您面临的第二个问题，关系变得复杂甚至可选的原因是由于前两个表未被归一化。由此产生许多问题。

• ，如果你在book仔细一看，你可能会注意到，同样的book（标题）被重复

• 同样，有（一）一书没有区别在它存在的条件世界及（b）一书，由成员所有的副本，可供借用

  • 如。该评论是关于现有的book一次，并且适用于book的所有副本;而不是拥有的book。
    。

• 你的“关系”表中也有数据，数据重复。

• 所有这些重复的数据需要保持并保持同步。

• 如果数据是标准化的，所有这些问题都会被消除。

因此（因为你正在寻找的“最佳办法”），该序列是第一数据标准化，之后（毫无疑问）的关系很容易，不复杂，不会有重复数据（以表或关系）。

• 正火的时候，最好是现实世界（不是整个现实世界，但无论你是在数据库中执行它的一部分）进行建模。这将数据库与变更的影响隔离开来，并且将来的功能扩展不需要更改现有的表。

• 同样重要的是使用正确的名字表和列，出于同样的原因。 group在非特定的情况下，将在您实施其他某种形式的分组时出现问题。

• 的关系能够在正确的“水平”被定义现在，正确的表之间。

• 需要在移动的所有内容上粘贴Id列严重阻碍了您理解数据和归一化过程以及抢夺关系能力数据库的能力。

  • 请注意，现有密钥已经是唯一且有意义的，简短且高效，不需要额外的代理键（及其附加索引）。作为外键，MemberIds`显示它们在其中使用的明确角色。

• 注意，当你认为你的问题的空间不是那么简单，它是作为一个案例研究，并与运教程为SQL（如MS SQL中，Sybase）。

▶Social Library Data Model◀

读者谁是不熟悉标准建模关系型数据库可能会发现▶IDEF1X Notational◀有用。

我已经提供了支持借阅所需的结构，以再次说明在归一化数据上实现关系是多么容易，并且显示借用所依赖的正确表格（它不在任何书籍和任何人之间;仅在国有书籍可以借用）。

• 这些问题非常重要，因为它们定义了数据库的参照完整性。

• 同样重要的是落实在数据库本身，这是标准的位置（而不是在应用程序代码，所有的地方）。声明式参照完整性是IEC/ISO/ANSI标准SQL的一部分。这个问题有一个数据库设计标签。

• 无法在非SQL中定义或强制实施引用完整性（有时可以定义引用完整性但它没有被强制执行，这会造成混淆和欺诈）。尽管如此，您可以设计和实现特定非SQL支持的数据库的任何部分。

如果您有任何不明白的地方，请随时提问，作为评论或作为您的问题的编辑。