一般来说，如果我在使用预先计算的值显示到用户
或
存储原始数据并即时计算正确的显示值是否更好？
一个示例（与我的项目相关）类似于以下内容：
您有一个计时器应用程序。就我而言，它使用核心数据。它没有连接到网络，而是在计算机或移动设备上运行的独立应用程序（用户选择）。该应用程序存储原始开始时间和原始结束时间。应用程序需要显示事件的持续时间和事件发生的时间间隔。存储预先计算的“持续时间”时间，甚至是用于输出的预先格式化的持续时间字符串会更好，还是动态计算持续时间更好，可以这么说，用于显示？
间隔也是如此，尽管涉及另一层，因为当我在数据库中创建/删除/更新一行时，我将更新受此影响的项目的间隔。或者，在应用执行时进行计算会更好吗？
郑重声明，我并不是要进行微优化。我试图找出减少我必须维护的代码量的最佳方法。如果性能因此得到改善，那就这样吧。
想法？
【问题讨论】：
标签： iphone objective-c database performance core-data
通常，您会希望避免在数据库中计算值（来自现有的列/表），除非分析绝对表明它们是必要的（即，数据库性能不佳或服务器上的负载过大）。对于数据格式化来说更是如此，这几乎总是应该在客户端执行，而不是浪费数据库服务器周期。
当然，执行计算所必需的任何数据都应存储在数据库中。
当您谈到减少需要维护的代码量时，请记住 DBA 也需要维护存储过程代码和表模式。将维护职责从开发人员转移到 DBA 并没有消除工作，它只是转移了工作。
最后，数据库更改通常会级联到许多应用程序，而应用程序更改只会影响该应用程序。
【讨论】：
我将计算值存储在数据库中的唯一时间是出于历史目的需要它。你会一直在会计软件中看到这一点。
例如，如果我正在处理发票，我通常会保存计算出的发票总额，因为以后计算总额的方式可能会发生变化。
我有时也会使用视图在数据库服务器上执行实际计算。
与许多其他事情一样，“这取决于”。对于您描述的情况，我倾向于将计算保留在代码中。如果您确实选择使用数据库，您应该使用视图来动态计算而不是放入静态值。否则更改开始时间或结束时间而忘记更改持续时间的风险会太高:)
【讨论】：
这实际上取决于您是想要纯净（保持数据干净）还是快速。桌面计算能力有助于提高纯度，高速内核和大内存空间使表格单元的字符串组合成为可能与大型数据集。
但是在手机上，甚至是 iPhone 4 上，为一组 1000 个对象计算 UITableViewCell 的单个 NSString 需要相当长的时间，这可能会影响您的用户体验。
因此，请根据您的用例调整平衡。持续时间听起来不会改变，所以我会预先计算并存储持续时间和显示字符串（从 DBA 的角度来看感觉很棒，但它会在手机上快速呈现）。
对于间隔，听起来您实际上需要另一个实体，将间隔与一组事件相关联。然后，每次关系发生变化时（即，您将实体添加到关系中，更新间隔），预先计算/维护此计算也很容易。
【讨论】：