Mysql 不必要的规范化
我的朋友和我正在建立一个网站，但有一个很大的分歧。该网站的核心是一个关于“人”的评论数据库。基本上，人们可以输入评论，也可以输入评论涉及的人。然后，查看者可以在数据库中搜索评论或人名部分中的单词。它完全由用户生成。例如，如果有人想对一个人的名字的错误版本发表评论，他们可以，这没关系。因此，可能会有不同的人的多个拼写被列为几个不同的条目（一些是中间名，一些是昵称，一些是错拼的，等等），但这一切都没问题。我们不在乎人们是否对随机的人或虚构的人发表评论 无论如何，问题在于我们如何构建数据库。现在，它只是一个表，注释ID作为主键，然后有一个字段用于注释所涉及的“人员”： 评论ID-评论-人物 1-“他很奇怪”-约翰·史密斯 2-“臭女孩”-珍妮 3-“同性恋”-约翰·史密斯 4-“欠我20美元”-Jennyyyyyyyy 一切正常。使用数据库，我可以创建页面，列出特定“人”的所有“评论”。然而，他沉迷于数据库没有规范化。我读了很多关于正常化的书，发现他错了。该表目前是标准化的，因为注释ID是唯一的，并且规定了“注释”和“人”。现在他坚持认为“人”应该有自己的表，因为它是一个“东西”。我认为这没有必要，因为即使“人”真的是一个更大的容器（一个“人”可以有很多关于他们的“注释”），数据库似乎运行得很好，“person”是注释ID的一个属性。我使用各种PHP调用进行不同的SQL选择，使其在输出和用户可以搜索和查看结果的不同方式上神奇地显得更加复杂，但实际上，设置非常简单。我现在让用户用大拇指向上和向下对评论进行排名，我在同一张表上保留一个“分数”作为另一个字段 我觉得目前没有必要为唯一的“person”条目单独设置一个表，因为“person”没有自己的“score”或任何属性。只有评论可以。我的朋友是如此的缺乏说服力，这对提高效率是必要的。最后我说，“好吧，如果你想让我创建一个单独的表，让‘person’作为它自己的字段，那么第二个字段会是什么呢？因为如果一个表只有一列，它似乎没有意义。我同意我们以后可能会创建一个需要，将‘person’作为它自己的表，但我们可以处理这个问题。”然后他说字符串不能是主键，我们将把当前表中的“person”转换为数字，数字将是新的“person”表中的主键。对我来说，这似乎是不必要的，它会使当前的表格更难阅读。他还认为，不可能在以后创建第二个表，我们现在需要预测，我们以后可能需要它Mysql 不必要的规范化,mysql,sql,database,database-design,database-normalization,Mysql,Sql,Database,Database Design,Database Normalization,我的朋友和我正在建立一个网站，但有一个很大的分歧。该网站的核心是一个关于“人”的评论数据库。基本上，人们可以输入评论，也可以输入评论涉及的人。然后，查看者可以在数据库中搜索评论或人名部分中的单词。它完全由用户生成。例如，如果有人想对一个人的名字的错误版本发表评论，他们可以，这没关系。因此，可能会有不同的人的多个拼写被列为几个不同的条目（一些是中间名，一些是昵称，一些是错拼的，等等），但这一切都没问题。我们不在乎人们是否对随机的人或虚构的人发表评论 无论如何，问题在于我们如何构建数据库。现在，它只
谁是对的？我认为你的朋友是对的 那个人应该住在另一张桌子上，你们应该试着正常化。不过，不要做得太过分
从长远来看，你可能想对你的网站做更多的事情，比如说你想给一个人附加多个文件（如图片），那么你会非常感谢规范化。我会投你朋友的票。我喜欢对未来进行规范化和规划，即使你从来都不需要它，但这种规范化非常容易做到，几乎不需要时间。您可以创建一个查询的视图，以使SQL更干净，并消除您自己加入表的需要。如果您已经达到了所有功能，并且没有扩展功能的计划，我认为您可以保持原样
如果您计划添加更多内容，即允许人们拥有帐户，或者其他任何内容，我认为将您的数据分离到Person、Comments表中可能是明智的。这并不难，而且使扩展功能更容易 事情是这样的。无论何时你创造了一些东西，你都要确保它有成长的空间。您希望尝试为您的计划预测未来的项目和未来的进展。在这个场景中，您说得对，目前不需要添加仅包含1个字段的persons表（不计算ID，假设您有一个int-ID字段和一个人名）。但是，在将来，您可能希望为这些人提供其他属性，如名字、姓氏、电子邮件地址、添加日期等
虽然过度规范化肯定是有害的，但我个人会创建另一个更大的表来容纳具有附加字段的人员，以便将来可以轻松添加新功能 嗯，有两个学派。有人说，以尽可能最规范化的方式创建数据模型，如果需要更高的效率，则取消规范化。另一种基本上是“做工作所需的最低限度的工作，然后随着需求的变化而改变”。也称为YAGNI（您不需要它） 这一切都取决于你对未来的看法。如果这就是一切，那么你的方法可能是好的。如果你打算随着时间的推移用新功能来改进它，那么你的朋友是对的。你是对的
Personpersonuser -> id | username | password | email
comment -> id | user_id | content
SELECT user.username, comment.content FROM user JOIN comment WHERE user.id = comment.user_id;