我有一个 TSQL View 。除了几列之外，它非常基本，因为它只是执行一些连接，然后将所有内容粘合在一起以呈现应有的良好 View 。然而，少数不那么简单的列使得 View 代码很难扩展，现在新的需求出现了，复杂的列的业务逻辑变得无效。
无需过多详细说明，我的数据库中有一个表:
tblEmployment
这由“就业”行组成。每次对于给定的就业情况，行中的任何列发生变化(假设 employmentTitle 发生变化)，当前行都会被推送到另一个表 tblEmploymentHistory 中，并且tblEmployment 中的行已更改，因此它包含最新的 employmentTitle 。
本质上， View 的作用是尝试将 tblEmployment 上的 tblEmploymentHistory 与唯一的 EmploymentIdentifier 连接起来，这是有道理的。
View 中更复杂的列将尝试通过对它连接在一起的行(即从 elapsedTime )进行各种计算来计算一个数字(每行 tblEmployment and tblEmploymentHistory )。为了获取耗时，它根据规定的业务逻辑执行计算，例如只有历史记录表中的特定日期时间列才应计入总 elapsedTime，并且仅当该行中的其他列设置为特定值等时才应这样做。
现在新的需求进来了，业务逻辑比以前复杂了很多。我发现很难扩展 View 以包含此内容，因为它变得非常困惑，并且我认为这可以在应用程序层中更加结构化地完成，其余业务逻辑也驻留在应用程序层中!
废弃 View 并将其移动到我的应用程序的应用程序层是否“正确”？显然，拥有 View 的好处是速度快，并且在代码中计算大约 100.000 行将需要一些时间。但是，可以通过过滤掉行来优化它，使数字在 10.000 左右。
解决这个问题的“标准”和最干净的方法是什么？
最佳答案
答案取决于几件事。首先，确保数据库正在执行基于集合的工作。如果您开始使用游标(一般来说)或某种循环，最好将其放在应用程序中。关系数据库以这种方式工作效率不高。我要考虑的另一件事是您工作环境的标准是什么？您所在的数据库中是否还维护着其他类似的内容？如果是这样，您可能希望保持一致。
最终，无论什么最有效地返回这些结果，并且不影响其他查询，都应该是答案。
关于sql-server - 包含太多业务逻辑的 (T)Sql View ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32480152/