sql - 超正常化的危险？

Question

我和几位同事面临着一个对性能有严重影响的架构决策:我们的产品包括一个 UI 驱动的架构构建器，它允许非程序员为 Web 应用程序构建他们自己的数据类型。目前，它在幕后构建了正确规范化的模式，并包含一些复杂的逻辑来更改模式并在管理员更改数据类型时自动迁移遗留数据。

规范化模式过去曾遇到性能瓶颈，并已安排重大重构。其中一组开发人员希望将数据类型的每个属性存储在一个单独的表中，以便对数据类型的更改永远不需要更改模式。 (例如，只需更改应用程序逻辑，就可以将单个属性转换为 1:n 关系。)

因为早期的基准测试表明这将导致巨大的性能损失，所以他们在应用程序代码中构建了一个缓存层，用于维护每种数据类型的非规范化版本。虽然它确实加快了查询速度，但我对应用程序层将承担的复杂性持怀疑态度，但我希望得到反馈——我是不是很悲观？其他人是否成功部署了此类解决方案？我应该坚持我的观点，还是将复杂性从“架构修改工具”转移到“架构镜像工具”是一件好事？

Answer 1

The normalized schemas have hit performance bottlenecks in the past, and a major refactoring has been scheduled. One of the groups of developers wants to store every property of the data types in a separate table, so that changes to the data types will never require schema altering. (A single property could be turned into a 1:n relationship, for example, just by changing application logic.)

这对我来说听起来是个坏主意。

它会搞乱你的数据库性能。如果您将这些内容存储在一行中，它们将在物理上一起位于磁盘上，并出于锁定等目的将它们视为一件事。

您编写的查询将需要大量额外的连接，并且会非常痛苦。您最终将编写 View 以将其恢复为最初应有的样子。

所描述的场景可能永远不会发生，因此您放慢了应用程序并使其复杂化，但可能没有任何好处，

如果确实发生了，并且您将不得不重新编码和测试一堆应用程序代码，那么此时更改数据库有什么额外的努力？您可以创建子表，通过更新将数据复制到其中，然后从父表中删除列

如果您成功了，将来一个不同的应用程序可能会附加到您的数据库。他们将无法分辨真正的模式是什么，因为该信息由您的应用程序保存。数据库中的模型数据。

如果 (a) 内存过多，(b) 扩展到多个应用程序服务器，(c) 有不同的应用程序连接到数据库，则应用程序服务器上的缓存可能会变得棘手。您正在解决由您自己造成的性能问题。

如果每个列都位于子表中，您将无法在多个列上创建索引。