3

我需要一个让我困惑了一段时间的 SQL 决定的帮助。

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

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

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

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

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

4

2 回答 2

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.

使用此设置，您不会浪费任何列，而是将共享的内容放在一起，同时在需要时仍可轻松地将两种类型的故事在逻辑上分开。

于 2013-10-21T19:54:25.463 回答
0

要做出这样的决定，您必须考虑是否只想将字段插入到您的表格中，而不是其他任何内容。例如

故事和故事类型，如果一个故事可以有多种类型的故事和/或多个故事的类型，那么是的，您必须制作一个特定的表格类型的历史，但如果只有一种类型的故事涉及一个故事，那么您插入类型信息（名称，描述等...）直接进入故事表。

于 2013-10-21T20:02:24.810 回答