我们是否应该总是删除计算出来的属性，即使它是一个关键而复杂的计算？

Question

数据库设计的“第三种范式”要求您删除函数依赖关系。它试图消除冗余，从表中删除可以从其他字段中计算的任何属性(字段)。例如，当您引用另一个实体时，您只存储它的密钥。您不需要存储来自这些引用实体的属性副本，因为这意味着每次更改引用实体时都必须更新它们。

另一种情况是一个属性，如高度。你想知道一个人的身高，但在你的申请中，你可能想知道不同的单位:米，脚，天文单位。但是您不需要存储所有这些值，您应该删除计算出来的字段，因此您只保留其中一个字段(当然是米)，并且在需要时计算转换后的值“动态”。

你也不储存像年龄这样的东西，你从出生日期算出它们。在这种情况下，年龄随时间变化的事实也起着一定的作用。如果您不这样做，您的数据将很快是不正确的，除非您不断地更新它。

现在假设您有一个显示每个用户星象符号的社交网络。我们为每个用户显示他或她的符号，这是根据出生日期和时间计算的，也是根据用户选择的占星学传统(例如西方或汉语)计算的。计算某人的星座是一个相当专门和涉及的计算，但无论如何，你可以调用从占星学图书馆和计算。您将如何设计这个数据库，删除这个功能相关的属性，或者计算用户的符号一次，或者每次她更新她的出生日期，然后将它存储在数据库中，忘记在您系统的其他部分计算一个符号的可能性，或者您会用铁拳执行"3NF“规则吗？如果用户坚持认为她的符号应该不同于您的算法计算的符号，那么您如何看待能够调整用户的符号的潜在好处呢？

现在假设有一个新的应用程序。你正在为陆军建立一个系统，为新征兵选择可能的职业。你的系统的一部分是一台巨大的坏屁股模式识别机，它是在ORNL开发的，它根据大量来自你的数据库的数据，告诉你应征者可以从事哪些职业。这种模式识别方法考虑的是每个人的身高、出生日期、病历、成绩单，还会看一长串人对两份问卷中的一份的答案。它还考虑到了由高级军官填写的评估问卷，并对每年的所有应征士兵进行了分析，同时提出了一些参数，比如前馈神经网络。这种神经网络比整个模式识别系统简单，但它仍然是一个相当复杂的计算，而不仅仅是一个温度单位的转换。然而，你可以把它看作是一个“黑匣子”，当你从数据库中提取他的记录时，它可以告诉你每个应征者的命运。

在陆军日历上的某个特定日期，进行了分析，找到了ANN参数，现在您可以运行黑匣子，告诉每个应征士兵在未来一两年要做什么。这是件很重要的事。你将决定人们的职业，你将派一些人在厨房操作烤箱，另一些人驾驶坦克。每个人都会登录军队的网络，查看他们的职业，并在他们的个人网页上看到结果。

现在，小黑匣子在那里，它根据从数据库中提取的属性输出这个重要值。属性和参数可能永远不会改变，对征兵命运的计算可能总是正确的，从第一天开始就会有相同的值。但是你真的会把它放在数据库之外，只为了遵循“删除计算的属性”规则吗？

这不仅仅是年龄、星座或温度转换的计算。模式识别系统确实是一种计算属性的路径。但是你真的想把它永远保存在你的系统里，一遍又一遍地重新计算这个非常重要的东西吗？或者，你会认为每件事都计算一次，而忘记了这个神奇的黑匣子的存在更好吗？我的意思是，只要每天运行所有这些疯狂的模式识别代码，然后选择结果，并将它们记录在数据库中。当有人登录查看他的分析的输出时，使它成为一个无聊的数据获取过程，并留下所有的花瓣识别“兴奋”下一次。

另一种更明显的情况是:你经营一家像亚马逊这样的网络商店。您有一种模式识别方法来向人们推荐书籍，这种方法是从您DB中的用户记录中输入的。您是否会在需要当前建议的时候一直运行它，还是将模式识别框视为与系统其他部分分离的东西，只需将其结果从其他程序可以读取的数据库中输入？有一个控制，例如，确保你不会在尴尬的时刻转换建议，这不是很好吗？不要太担心计算负担，假设有很好的内存和计算资源。

你认为删除计算过的属性的规则永远不应该被打破，还是说可以将非常重要的属性的结果存储在数据库中，这些结果是通过非常复杂和精细的模式识别方法计算出来的？在某些情况下，我们不应该假装你实际上不能按需计算，而只是把这些结果记录在那里，这样的结果无论如何都不会更新吗？

Answer 1

故意，司法反正规化是“允许”缓存的结果昂贵的计算。转换单元或计算年龄将是不应该缓存的廉价操作的例子，但您引用的其他示例看起来是合适的。

根据DBMS的不同，您可以将表保持规范化，并实现缓存“在上面”：

• 一些DBMSes支持物化观点 --像一个常规视图，但是持久化，所以不需要每次查询时都重新计算它。
• 一些支持计算字段的DBMSes (又名。，也支持持久化它们(一个例子是MS下的坚持关键字)。