如果我只有几对多，我还应该使用多对多数据库结构吗？答案

【问题标题】：Should I still use many-to-many db structure if I only have a few-to-many?如果我只有几对多，我还应该使用多对多数据库结构吗？
【发布时间】：2011-09-25 11:26:36
【问题描述】：

我是 Web 开发的新手，我真的可以使用一些建议。提前谢谢大家！

我有一个表格，要求用户从 1 到 10 对他们在多个领域（心理、身体、乐趣）的体验进行评分。总共大约有 10 个领域。用 areaID 和 userID 制作区域表和交集表是否值得？在这种情况下，只创建一个包含 11 列的表（每个区域一个加上一个用户 ID）不是更容易吗？

我知道带有 areaID 键的“区域”表将是最强大的，并且允许我稍后添加更多区域，但我真的不认为自己会这样做。另外，由于我只希望

最后，我应该使用多对多结构的临界点是什么？稍后在表单中，我让用户从 1 到 4 对大约 30 个字段进行评分。我应该在那里使用两个表系统吗？

再次感谢！

【问题讨论】：

您确定区域的数量不会永远改变吗？你确定你可以确定吗？顺便说一句，“多对多”中“多”的定义实际上是“不止一个”。

标签： php mysql html webforms

【解决方案1】：

两者都有道理，但我会选择多对多方法，因为您可以在区域表中指定每个区域的名称（并且可能添加一些 cmets 1 或 10 对于该特定区域的含义等。 .)

【讨论】：

【解决方案2】：

假设您要计算每个用户的区域数。如果你使用一个有 11 列的表，你会怎么做？

使用交集表实现这一点。你会很高兴你这样做了。

【讨论】：

【解决方案3】：

对此没有错误的答案，但请考虑一下：您确定该数字将保持在 10 不变吗？

就个人而言，我仍然会使用多对多关系。这是更优雅的解决方案，而且在我看来，更好。然而，把工作做好往往是在浪费时间。

【讨论】：

如果您想制作一个快速原型，那是在浪费时间，否则在您将其交给其他人之前，技术债务不会咬您一口。
做好一项工作可能并不总是在以后得到充分的赞赏，但如果你事先没有做好/灵活地完成这项工作，你肯定会浪费更多的时间重新设计。
有时，编程由您使用一次然后丢弃的脚本组成。我非常相信像 OOP 这样鼓励灵活性的范式，但是为了同样的目的，你会使用一两次的三行粉笔 Perl 比八十行优雅的 Java 要好。
哦，当然。我并不是要暗示一个人应该总是以“长”的方式去做。我的重点主要在于这一点，因为提问者的问题似乎是“漫长”方式最好的情况，并且因为您可能浪费更多时间重新设计本应比您更灵活的东西当您设计的东西比必要的更灵活时。

【解决方案4】：

我会总是使用适当的交集表为多对多关系建模，因为您永远无法预测未来会发生什么。

【讨论】：

【解决方案5】：

最好使用单独的子表。连接的 SQL 开销极小，您可以完全灵活地选择要允许的条目数/数，而无需更改数据库结构。

现在可能只有 10 个区域，但 PHB 因在发布前一小时改变对“基石”的想法而臭名昭著。

【讨论】：

叹息。 . .好的。感谢您抽出宝贵时间为 FNG 提供建议
那么将这些值存储在交集表中的好方法是什么？我是否需要将每个区域名称与区域表中的行进行比较，找到适当的 areaID，然后将其添加到交集表中？有没有更好的办法？