数据库设计示例，对吗？

Question

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

我想最终消除混乱，我的所有研究都使我怀疑自己，所以这是当第三方建议作为一种保证时，因为你们所有人都可能比我在这一领域更有经验，所以我很谦逊您的意见。

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

第一个设计

因此，在上表中，以我有限的理解，它与许多章中的故事是一对多的关系。

第二设计

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

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

举个例子：如果创建一个故事，那么您还必须至少创建1章，然后再添加更多内容。

  

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

     

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

     

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

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

P.S。以后我将以此为基础进行所有其他表格设计和操作。

编辑：

用户与故事表的关系（我基于此建立了我的故事-章节关系）。

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

User to Story

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行，而章节和故事之间的链接将消失，但行不会消失
  • 基于第一个设计，是的，您应该删除孤立的章节或仅禁用具有链接到其的章节的故事的删除