database-design - 数据库设计示例，是否正确？

Question

我想以一个家庭为例，但我忘记了父母对孩子有 2 个对象（丈夫和妻子），所以它增加了不必要的工作，所以我只选择了一个更简单的故事数据库。

我想最终消除我的困惑，我所有的研究都让我怀疑自己，所以这是第三方建议作为一种保证的时候，因为你们可能比我在这个领域更有经验，所以我尊重你的意见.

这是一个简单的布局：所有主键 id 都是自动递增的

第一个设计

所以在上面的表格中，在我有限的理解中，它是一个一对多的关系，就像一个故事到很多章一样。

二次设计

我在第二个设计中做对了吗，还是我误解了某些东西并使事情变得更复杂？

如果我的第二个设计是正确的，那么我应该如何对所有三个表进行 CRUD 操作？

例如：如果您创建一个故事，那么您还必须至少创建 1 个章节，然后您可以稍后添加更多。

-> 在故事表中创建故事行（插入）

-> 在章节表中创建章节行（插入）

-> 在story_chapter 表中创建story_chapter 行（插入）

上述程序是否正确？由于在story_chapter 表中story_id 和chapter_id 都是外键，所以在创建时两者都不能为空，因此我必须先创建故事行，然后是章节行，然后我可以为中间人创建行吗？story_chapter 表是否更依赖于章节表？如果一个章节不存在（如果用户在创建后删除了所有章节），那么我还必须删除 story_chapter 中与已删除章节相关的行，因此可以存在一个故事行，但其他两个不是必须的，但是如果一个章节确实存在，那么 story 和 story_chapter 也必须存在？

PS 我将把它作为我以后所有其他表格设计和操作的基础。

编辑：

用户到故事表的关系（我以此为基础建立了我的故事章节关系）。

1 个用户/作者可能有很多故事。

用户到故事

标签： database-design

Answer 1

在您的第一个示例中，任何故事都有很多章节，但每个章节只包含一个故事。

在您的第二个示例中，任何故事都有很多章节，每个章节都可以在每个故事中。这意味着您可以拥有以下内容：

1. 指环王

   1.1 LOTR - 第 1 章

   1.2 LOTR - 第 2 章

2. 50级灰度

   2.1 50 种灰色 - 第 1 章

   1.2 LOTR - 第 2 章

---

|-----------------------| |------------------------| |----------------------------|
|     story_chapter     | |         story          | |          chapter           |
|-----------------------| |------------------------| |----------------------------|
| story_id | chapter_id | | story_id | story_title | | chapter_id | chapter_title |
|     1    |     1      | |     1    |    LOTR     | |     1      |   Chapter 1   |
|     1    |     2      | |     2    | 50 Shades...| |     2      |   Chapter 2   |
|     2    |     3      | |------------------------| |     3      |   Chapter 1   |
|     2    |     2      |                            |----------------------------|
|-----------------------|

我认为这样做不是一个好主意，你应该坚持第一个例子。

关于您使用第二个示例的方式的问题：

• 你的插入程序是对的，你可以在故事之前创建章节，在这个设计中没关系
• 请注意，外键可能为 NULLABLE（可能取决于您的 RDBMS），因此在创建表时要小心
• 在这个设计中，当您删除一个故事时，您必须决定是否要删除其他故事的章节（请记住，它们与许多故事相关联）。如果没有，您可以删除该story_chapter行，章节和故事之间的链接将随之消失，但行不会
  • 基于第一个设计，是的，您应该删除孤立的章节，或者只是禁用删除链接到它的章节的故事