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