图书阅读器应用的数据库设计

Question

我正在尝试使用Postgresql为图书阅读器应用程序设计数据库。 一切正常，直到我开始存储章节为止。

假设有20,000本书，每本书最多可包含2000章。无论如何，我想不出来。

现在我的桌子是这样的：

书籍
-id
-标题
-cover_image
-观看次数

图书信息（这是一本书的详细信息）
-id
-标题
-说明
-作者
-类别
...

所需章节模型
-标题
-内容
-观看次数

我尝试过：
-要使用自定义类型（或Postgres术语中的复合类型），会导致字符串格式不正确，数据将被错误地保存，并且感觉不正确。
-要使用Chapter表，所有内容都会很好地存储到数据库中。但是“章”表上的行数太大（考虑一本书的平均章数为800）。另外，我通过SELECT WHERE book_id = BOOKS.id获取书的章节。显然不会扩展。

请帮助我。

P / s：我是数据库新手，请原谅。

Answer 1

问题是：您需要将章节与书籍分开进行吗？ 如果您不这样做，那么我认为您可以在BOOKS INFO表中创建JSON类型的“章节”列。然后，您可以将所有“书籍章节”以JSON格式存储在此列中。 查看此链接：https://blog.codeship.com/unleash-the-power-of-storing-json-in-postgres/

Answer 2

从关系的角度来看，您被迫使用像BookChapters这样的明细表，其主键为BookID和ChpaterID。我可以提出的有效缩放建议是，将大数据（内容？）分离到与BookChapters一对一相关的另一个表（BookChaptersContent？）中。它将像： 桌上书（BookId，...）PK（BookId） 表格BookChapters（FK BookId，ChapterId，标题，视图）PK（BookId，ChapterId） 表格BookChapterContent（FK BookId，FK ChapterId，内容）PK（BookId，ChapterId） 这将有助于使BookChapters的行大小保持较小，从而可以更快地进行搜索，并且最重要的是，将章节与章节内容隔离开来，就像从Books中隔离一样，您可以根据需要将其加入任一明细表。实际上这是有帮助的，因为例如当您浏览一本书时，您可以阅读所有章节而无需阅读其内容，然后可以按需查询章节内容。另一个示例是，当内容（BookChapterContent）被更新时，各章不受数据更新锁定（BookChapters）的影响。

Answer 3

  

它显然无法扩展。

不一定。

对于一个人类来说，这似乎是一个庞大的数字（20.000本书，共800章，= 16.000.000条记录），对于像Postgres这样的关系数据库引擎来说，微不足道-只要您可以按索引进行搜索。

因此，如果您在book_id上创建索引，则示例查询SELECT WHERE book_id = BOOKS.id应该扩展到亿万章-只要您不打算扩展到亿万用户。

通常，我对数据库优化的规则是首先构建干净的关系模型，并用示例数据填充它，看看它是否有效；使用索引等对其进行优化，添加更多硬件，并在证明有问题后才寻找替代方法。