我需要帮助做出一个让我困惑了一段时间的SQL决策。
我正在尝试制作一个短篇小说网站，用户可以在其中编写自己的故事并可以浏览彼此的故事等。我还有一本过去伟大作家写的经典短篇小说集。我对是否应该将两种类型的故事存储在同一个数据库表中感到困惑。
我想在某种程度上保持两种类型的故事（经典作者/用户）的不同，因为您应该能够搜索网站并从结果中过滤掉用户故事。但是我不能只在表中有一个数据库行来表示这一点，即布尔 CLASSIC，因为对于经典的短存储，其他几行也会有所不同 - 没有用户，日期将是 YYYY（即，1869 年）而不是用户提交它时的完整日期时间。
然而，我也不能完全证明将它们放在单独的表中是合理的。当大多数属性相同时，我真的应该为短篇小说提供两个不同的数据库表吗？目前，我正在经典短篇小说的用户行中填写NULL，并且我的过滤搜索有一个选项，可以仅搜索经典，该选项从用户为NULL的数据库中选择。不过，当您搜索一个包含数百万个用户故事的庞大数据库只是为了找到几千个经典故事时，这似乎会影响性能。
请注意，还有其他表，例如故事的标签，链接到短故事表。
所以我基本上是在问你们SQL专家 - 是否有足够的理由将这两种类型的信息分成不同的表？我目前正在开发中使用SQLite，但稍后将切换到MySQL或PostgreSQL。
我可能会使用"父子"表结构，其中跨表具有匹配的主键，如下所示：
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.
通过此设置，您不会浪费任何专栏，而是将共享的内容放在一起，同时在需要时仍可以轻松地将两种类型的故事在逻辑上分开。
要做出这样的决定，您必须考虑是否只想将字段插入到表中，而不是其他字段。例如
故事和故事类型，如果一个故事可以有几种类型的故事和/或几个故事的类型，那么是的，你必须制作一个特定的表类型的历史，但如果只有一种类型的故事涉及一个故事，那么你将类型信息（名称、描述等）直接插入到故事表中。