去标记数据结构本质上是一种代码优化，适用于正常的规则吗？

Question

Bloch的有效Java之一55: Optimize judiciously扩展了杰克逊的优化规则：

规则1:不要优化！规则2(专家)：不要优化！额外的Bloch规则1:在开发完成之前不要尝试它。额外的Bloch规则2:在实现优化之前和之后测量性能(您会惊讶的！)

从本质上讲，这就是我如何进行优化的方法。不过，我现在遇到的情况是，我使用的是反映业务领域的复杂但准确的OO数据结构。

我发现自己正在考虑实施大量的反歧视措施。

如果其他一切都是平等的，我应该吗？

这些规则适用于商业层面的去欧化是否只是另一种优化方法？

Answer 1

我对这些规定的问题是他们在和婴儿说话。总有一天，发现加速是必要的，老生常谈的S也帮不上忙。你得知道怎么做。

猜也找不到他们。如果有人看了代码并说“也许这可以做得更好”--这是猜测。

测量找不到它们。它可能告诉你没有问题，但如果有问题，它不会告诉你它是什么。

有些人更有帮助，说“使用分析器”。分析器可以给你漂亮的壁纸，但是他们只找到一种有限的速比。如果你让别人逃走，你就会错过这就是为什么。

有一种方法是有些人用。它不能给你漂亮的墙纸。它确实发现了分析器所做的任何加速，更多的是他们没有。

Answer 2

布洛赫的优化规则只是“过早优化是万恶之源”的一个变种，正确的解释是“先衡量，然后再优化。确保你的优化实际上会给你带来你想要的性能效益，在你花时间和金钱进行优化之前。”

我不一定同意将所有优化推迟到项目结束。一些优化必须在开发过程中完成；等到最后才能进行这样的优化实际上是不可能的。

Answer 3

我写这篇文章是为了强调规范化不仅仅是为了优化。在有些情况下，RDBMS不是当前问题的正确解决方案，而且可以使用文档数据库甚至文件系统来存储您的信息。然而，这个答案并不是要讨论这个问题。

规范化促进了优化，但它并不仅仅用于优化。规范化(如果正确的话)，会在数据存储级别产生一致的信息。在许多OLTP系统中，这种类型的一致性是非常可取的。这对基于海量数据的BI系统来说是有代价的，因此类似星型模式这样的替代方法可以用于此类系统。

例如，给定基于web的CMS应用程序，当客户更改其地址时，数据库级别上对该客户的所有引用都将指向一个(或最近的)地址信息。

此外，SQL与规范化完全一致地工作，以提供这种类型的一致信息。您可以使用规范化结构获得聚合函数、联接等的全部功能，从而降低代码复杂性。

报告生成工具在规范化结构中也能很好地工作。

对于企业应用程序来说，规范化是非常重要的，因此集成系统变得更加容易。

总之，规范化除了优化之外还有其他好处。