我有一个 TSQL 视图。除了几列之外,它非常基本,因为它只是进行了一些连接,然后将所有内容粘合在一起以呈现应有的漂亮视图。然而,不那么简单的少数列使得视图代码很难扩展,现在新的需求已经出现,使得复杂列的业务逻辑无效。
无需过多介绍,我的数据库中有一个表:
tblEmployment
这由“就业”行组成。每次一行中的任何列,对于给定的就业变化(假设是employmentTitle
变化),然后当前行被推入另一个 table tblEmploymentHistory
,并且行中的行tblEmployment
被更改,因此它包含最新的employmentTitle
。
从本质上讲,视图的作用是尝试将tblEmployment
ontblEmploymentHistory
与 unique 结合起来EmploymentIdentifier
,这是有道理的。
视图中更复杂的列将尝试elapsedTime
通过从它连接在一起的行(即 from )进行各种计算来计算一个数字(对于每一行tblEmployment and tblEmploymentHistory
)。为了获得经过的时间,它根据规定的业务逻辑执行计算,例如,只有历史表中的特定日期时间列才应计入总的经过时间,并且只有在该行中的其他列设置为特定值等时才应该这样做。
现在有了新的需求,业务逻辑比以前复杂多了。我发现很难扩展视图以包含它,因为它变得非常混乱,而且我觉得这可以在其余业务逻辑也驻留的应用程序层中更加结构化!
废弃视图并将其移动到我的应用程序的应用程序层是否“正确”?显然,拥有视图的好处是速度很快,并且在代码中对大约 100.000 行进行计算需要一些时间。但是,可以通过过滤掉行来优化它,使数字在 10.000 左右。
解决这个问题的“标准”和最干净的方法是什么?