3

假设我让用户检查她说的语言并将其存储在数据库中。重要的附注，我不会在 db 中搜索任何这些值，因为我将有一些单独的搜索引擎进行搜索。现在，存储这些值的明显方法是创建一个表，如

UserLanguages
(
 UserID nvarchar(50),
 LookupLanguageID int
)

但是该站点将是高负载的，我们正在尝试尽可能消除任何开销，因此为了避免在 UI 上显示结果时与主成员表连接，我正在考虑将用户的语言存储在主表中，让它们逗号分隔，如“12,34,65”

同样，我不搜索它们，所以我不必担心必须对该列进行全文索引。

我真的没有看到这个解决方案有任何问题，但是我忽略了什么吗？

谢谢，安德烈

4

9 回答 9

16

不。

  • 你现在不搜索它们
  • 除了这种情况，数据对任何事情都没有用
  • 没有数据完整性（例如没有 FK）
  • 您仍然需要更改为“英语，德语”等才能显示
  • “给我所有说 x 的用户”= FAIL
  • 该列表实际上是一个演示问题

不过，这是您的系统，我期待稍后回答不可避免的“帮助”问题……

于 2009-09-28T19:26:25.097 回答
12

您现在可能不会错过任何东西，但是当您的需求发生变化时，您可能会后悔那个决定。您应该像您的第一直觉建议的那样将其标准化存储。这才是正确的做法。

您的建议是经典的过早优化。您还不知道该连接是否会成为瓶颈，因此您不知道您是否真的在购买任何性能改进。等到你可以分析这个东西，然后你就会知道那个部分是否需要优化。

如果是这样，我会考虑使用物化视图或其他方法，使用标准化数据将答案预先计算到不被视为记录簿的缓存中。

更一般地说，如有必要，可以进行许多可能的优化，而不会以您建议的方式影响您的设计。

于 2009-09-28T19:27:55.937 回答
11

这种类型的存储几乎总是回来困扰我。一方面，你甚至不是第一范式。另一方面，某个经理或其他人肯定会回来说......“嘿，现在我们存储了这个，你能给我写一份关于......的报告吗？”

我建议采用标准化设计。把它放在一个单独的桌子上。

于 2009-09-28T19:21:22.550 回答
5

问题：

  1. 你失去了加入能力（显然）。
  2. 您必须在每个页面加载/回发时重新解析列表。这导致更多的代码客户端。
  3. 您失去了试图保持数据库完整性的所有伪装。试想一下，如果您决定稍后删除一种语言......修复所有用户配置文件的 sql 将是什么？
  4. 假设您的各种配置文件选项存储在数据库的查找表中，您仍然必须为每个配置文件页面运行“30 个查询”。如果不是，那么您必须为每个小更改编写代码部署。糟糕，非常糟糕。
  5. 将设计决策建立在“不会发生”的事情上绝对是失败的秘诀。当然，商界人士说他们永远不会这样做……直到他们想到一个绝对必须这样做的理由。今天。在您完成编码后，这将很快出现。
  6. 正如我在评论中所说，对低使用率页面的 30 次查询不算什么。不要出汗，绝对不要优化，除非你确定它是必要的。猜猜它的个人资料页面有多少查询？
于 2009-09-28T20:14:27.927 回答
4

我通常会远离您描述的解决方案，当您以这种方式存储关系数据时会自找麻烦。

作为替代解决方案：您可以存储为一个位掩码整数，例如：0 - 无选择 1 - 英语 2 - 西班牙语 4 - 德语 8 - 法语 16 - 俄语 - 等等 2 的幂

因此，如果有人选择了英语和俄语，则值为 17，您可以使用按位运算符轻松查询这些值。

于 2009-09-28T19:27:15.220 回答
4

过早的优化是万恶之源。

编辑： 显然我的观察背景被一些人误解了——因此遭到了反对。所以我会澄清。

非规范化模型以使事情变得更容易和/或“更高性能” - 例如创建连接列来表示业务信息（如在 OP 案例中） - 我称之为“过早优化”。

虽然可能存在一些极端情况，即没有其他方法可以获得特定问题域所需的必要性能——但很少有人认为是这种情况。一般来说，这种过早的优化会导致长期的悲痛，因为它们很难撤消——一旦数据模型投入生产，就会比最初部署时付出更多的努力。

在设计数据库时，开发人员（和 DBA）应该应用规范化等标准实践，以确保他们的数据模型表达正在收集和管理的业务信息。我不认为正确使用数据规范化是一种“优化”——它是一种必要的做法。在我看来，数据建模者应该一直在寻找可以重构为（至少）第三范式（3NF）的模型。

于 2009-09-28T19:34:01.703 回答
2

如果您不针对它们进行查询，那么通过将它们存储在类似于您的初始计划的形式中，您不会丢失任何东西。如果您是，那么以逗号分隔的格式存储它们会再次困扰您，我怀疑任何速度节省都会显着，尤其是当您考虑将它们翻译回来所需的工作时。

于 2009-09-28T19:53:29.460 回答
1

您似乎非常担心添加一些额外的查找表连接。根据我的经验，实际传输 HTML 响应并让浏览器呈现它所花费的时间远远超过了一些额外的表连接。特别是如果您使用索引作为主键和外键（应该如此）。就像您正在计划一次多日的越野旅行，而您担心额外的 10 分钟浴室停留时间。

对于如此小的优化（可能没有必要甚至不引人注意），缺乏长期的灵活性和数据完整性是不值得的。

于 2009-09-28T20:39:06.700 回答
0

不不不不不不不不不不不不不不不不不不不！！！！！！！！

正如上面几篇文章中所说的那样。

如果您想对这场辩论提出相反的看法，请查看 wordpress。表格塞满了分隔数据，这是一个很棒的简单平台。

于 2009-09-28T20:18:04.930 回答