何时对两种略有不同类型的信息使用单独的 SQL 数据库表？

Question

我需要有关 SQL 决策的帮助，该决策让我困惑了一段时间。

我正在尝试制作一个短篇小说网站，用户可以在其中写自己的故事，也可以浏览彼此的故事等等。我还收集了过去伟大作家写的经典短篇小说集。我很困惑是否应该将两种类型的故事存储在同一个数据库表中。

我希望在某种程度上保持两种类型的故事（经典作者/用户）不同，因为您应该能够搜索网站并从结果中过滤掉用户故事。但我不能只在表中使用单个数据库行来表示这一点，即布尔值 CLASSIC，因为对于经典的短存储，其他几行也会不同 - 没有用户，日期将是 YYYY （即 1869）而不是用户提交时的完整日期时间。

但我也不能完全证明将它们放在单独的表中是合理的。当大多数属性相同时，我真的应该为短篇小说拥有两个不同的数据库表吗？目前，我正在将 NULL 填充到经典短篇小说的用户行中，并且我的过滤搜索有一个仅搜索经典作品的选项，该选项从用户为 NULL 的数据库中进行选择。不过，当您在包含数百万个用户故事的庞大数据库中搜索只是为了找到几千个经典故事时，这似乎会影响性能。

请注意，还有其他表格，例如链接到短篇故事表格的故事标签。

所以我基本上问你们 SQL 专家 - 是否有足够的理由将两种类型的信息分成不同的表？我目前在开发中使用 SQLite，但稍后会切换到 MySQL 或 PostgreSQL。

Answer 1

我可能会采用“父子”表结构，其中跨表具有匹配的主键，例如：

Stories: StoryId (PK), StoryType (U or C), StoryText, etc. (all of the shared stuff)
UserStories: StoryId (PK and FK), UserId, etc.
ClassicStories: StoryId (PK and FK), AuthorName, etc.

然后，如果需要，您可以围绕它们构建两个视图：

V_UserStories: StoryId, StoryText, UserId, etc.
V_ClassicStories: StoryId, StoryText, AuthorName, etc.

通过这种设置，您不会浪费任何专栏，您可以将共享的内容放在一起，同时仍然可以在需要时轻松地将两种类型的故事在逻辑上分开。