我有一个表，在 DateTime 列中存储了一个startingDate。
一旦我有了startingDate值，我应该计算
- number_of_days,
- number_of_weeks
- number_of_months 和
- number_of_years
所有从startingDate到当前日期。
如果您打算在应用程序的两个或多个位置使用这些值，并且您非常关心应用程序的响应时间，您宁愿在视图中进行计算还是为每个位置创建计算列以便可以直接查询表？
问问题
2026 次
3 回答
0
计算列易于维护，并为您的问题提供了理想的解决方案——我最近使用过这样的解决方案。但是，请注意这些值是在请求时计算的（当它们被 SELECT 时），而不是在将行插入到表中时计算 - 所以性能可能仍然是一个问题。如果您可以将工作从应用程序服务器卸载到数据库服务器，这可能是可以接受的。视图在被请求之前也不存在（除非它们被具体化），因此在运行时也会有开销，但是，它再次位于数据库服务器上，而不是应用程序服务器上。
于 2013-04-09T07:18:53.710 回答
0
像几乎所有东西一样：这取决于。
正如@RedX 所暗示的那样，无论哪种方式，性能差异都可能不大，因此成为如何使用它们的问题。对我来说，这更像是一种感觉。
多次使用它们并不需要立即将我带到视图或计算列。如果我只在几个地方或少量代码路径中使用它们，我可能会在这些地方内联计算它们或使用 CTE。但是，如果它们被广泛使用或大量使用，我会同意视图或计算列。
如果您希望它们通过 ORM 工具可用，您还希望它们在视图或 cc 中。
我是在地方使用那些“计算列”个体还是在集合中使用它们？如果在集合中使用它们，我可能想要一个显示包含它们的表格的视图。
当我需要它们时，我通常是否希望它们与来自特定其他表的数据相关联？如果是这样，那将提出一个观点。
我是否基于这些计算值的原始表进行更新？如果是这样，那么我希望计算列避免在这些情况下加入视图。
于 2013-12-02T17:05:06.043 回答
0
计算列起初似乎是一个简单的解决方案，但我看到公司遇到了麻烦，因为当他们尝试使用 CDC 进行 ETL 以使用 Attunity 等工具进行实时变更数据捕获时，它不会识别计算列，因为值是不是永久存在的。所以有一些问题。此外，如果用户将多次检索列，从长远来看，您可以通过将该逻辑放入 ETL 工具或过程中并将其写入数据库一次而不是为每个请求计算多次，从而节省时间。
于 2017-02-22T15:26:54.763 回答