我和几位同事面临着一个具有严重性能影响的架构决策：我们的产品包括一个UI驱动的架构构建器，允许非程序员为Web应用程序构建自己的数据类型。目前，它在幕后构建了正确的规范化模式，并包含一些复杂的逻辑来改变模式，并在管理员对数据类型进行更改时自动迁移旧数据。
规范化的模式在过去已经遇到了性能瓶颈，并且已经安排了一次重大的重构。其中一组开发人员希望将数据类型的每个属性存储在一个单独的表中，以便对数据类型的更改永远不需要更改模式。 （单个属性可以转换为1：n关系，例如，只需更改应用程序逻辑。）
因为早期基准测试表明这会对性能造成巨大损失，所以他们在应用程序代码中构建了一个缓存层，用于维护每种数据类型的非规范化版本。虽然它确实加快了查询速度，但我对应用程序层将要承担的复杂性持怀疑态度，但我希望得到反馈 - 我是否感到悲观？是否已成功部署此类解决方案？我应该坚持使用枪支，还是将复杂性从“架构修改工具”转移到“架构镜像工具”是一件好事？
答案 0 :(得分：11)
规范化的模式已经命中 过去的性能瓶颈， 并且进行了重大的重构 调度。其中一组 开发人员希望存储每一个 a中数据类型的属性 单独的表，以便更改 数据类型永远不会需要架构 改变。 （单个财产可能是 变成1：n关系，因为 例如，只需更改应用程序 逻辑。）
这对我来说听起来不错。
答案 1 :(得分：5)
您描述的内容与我称之为规范化的内容不同。它更像是超级抽象 - 试图找到一些抽象级别，从中可以推导出其他所有东西。像javascript中的“对象”。如果你把它归结为合乎逻辑的结论，你就可以得到两张表;每个Object有一个表，其中包含ObjectTypeCode和ObjectId的列;另一个带有关联的表，有两个ObjectId列，第三个用于唯一性，第四个用于Value。
我建议您重新访问您的域模型。你描述的那个听起来很可怕（但不幸的是，我非常熟悉）。我有一个为我工作的人发明了一个叫做“物体”的桌子。有两个子表，ObjectAttributes和ObjectProperties。难以清楚地解释两者之间的差异。桌子（幸运的是）并没有持续多久。
答案 2 :(得分：2)
严格来说，没有“超规范化”这样的事情。如果将完全规范化的模式重构为另一个等效的完全规范化模式，则它们都被标准化。通常所谓的“超规范化”实际上是在追求除标准化之外的目标时的表分解。
如果我读对了你，我认为这不是你在原帖中概述的情况。好像你的小组正在讨论规范化架构和有些非规范化架构之间的争论。
当智能设计人员手动完成此操作时，在使用某些非规范化设计获得的性能优势与随后的非规范化的更新问题之间存在权衡。我希望你的产品做同样的事情会自动遭遇智能人体模式设计师所遭受的困难，然后是一些。
我猜你网站上的真正问题根本不是一个性能问题。相反，我认为让用户随意定义新数据类型的要求与从静态信息要求集合中精心设计的数据库获得相同结果的愿望之间存在冲突。
在我看来，这两个目标是不可调和的。数据库中最终的数据管理层由您的用户社区完成。他们甚至可能甚至没有在委员会会面，以决定哪些新定义将成为标准，哪些将被丢弃。除非我错过了我的猜测，否则架构可能充满了同义数据类型，其中不同的用户发明了相同的数据类型，但给它一个不同的名称。它可能还包含一些同名数据类型，其中不同的用户发明了不同的数据类型，但给了它们相同的名称。
每次尝试这样做都会导致混乱。这种混乱的第一个明显迹象是难以解决的性能问题，但这只是冰山一角。迟早，您将发现数据库中的内容是非托管数据。而且你会发现，用管理数据获得的收益不可能带来同样的收益。
如果我对此错了，我很想知道证明我错的例子。它代表了现有技术的根本进步。
答案 3 :(得分：0)