2

我有一个 TSQL 视图。除了几列之外,它非常基本,因为它只是进行了一些连接,然后将所有内容粘合在一起以呈现应有的漂亮视图。然而,不那么简单的少数列使得视图代码很难扩展,现在新的需求已经出现,使得复杂列的业务逻辑无效。

无需过多介绍,我的数据库中有一个表:

tblEmployment

这由“就业”行组成。每次一行中的任何列,对于给定的就业变化(假设是employmentTitle变化),然后当前行被推入另一个 table tblEmploymentHistory,并且行中的行tblEmployment被更改,因此它包含最新的employmentTitle

从本质上讲,视图的作用是尝试将tblEmploymentontblEmploymentHistory与 unique 结合起来EmploymentIdentifier,这是有道理的。

视图中更复杂的列将尝试elapsedTime通过从它连接在一起的行(即 from )进行各种计算来计算一个数字(对于每一行tblEmployment and tblEmploymentHistory)。为了获得经过的时间,它根据规定的业务逻辑执行计算,例如,只有历史表中的特定日期时间列才应计入总的经过时间,并且只有在该行中的其他列设置为特定值等时才应该这样做。

现在有了新的需求,业务逻辑比以前复杂多了。我发现很难扩展视图以包含它,因为它变得非常混乱,而且我觉得这可以在其余业务逻辑也驻留的应用程序层中更加结构化!

废弃视图并将其移动到我的应用程序的应用程序层是否“正确”?显然,拥有视图的好处是速度很快,并且在代码中对大约 100.000 行进行计算需要一些时间。但是,可以通过过滤掉行来优化它,使数字在 10.000 左右。

解决这个问题的“标准”和最干净的方法是什么?

4

2 回答 2

3

答案取决于几件事。首先,确保数据库正在执行基于集合的工作。如果您开始进入游标(一般而言)或某种循环,最好将其放在应用程序中。关系数据库以这种方式工作效率不高。我要考虑的另一件事是您工作环境的标准是什么?您所在的数据库中是否还维护了其他类似的东西?如果是这样,您可能希望保持一致。

最后,无论是最有效地返回这些结果,并且不影响其他查询,都应该是答案。

于 2015-09-09T13:26:12.157 回答
1

正如所承诺的,我将为您提供一个 UDF 方法的示例:在我的一个项目中,我将它与 40 多个不同的分层结构的 UDF 一起使用,以得到一个包含近 1000 列的结果集。

CREATE TABLE dbo.TestTable(Col1 INT,Col2 INT,Col3 INT);
INSERT INTO dbo.TestTable VALUES(1,2,3),(4,5,6),(7,8,9);
GO

CREATE FUNCTION dbo.TestFunc(@Prm1 INT,@Prm2 INT)
RETURNS TABLE
AS
RETURN
    SELECT @Prm1 AS Func_Prm1 --use names, which will be unique in any usage, this makes things much easier!
          ,@Prm2 AS Func_Prm2
          ,@Prm1 * @Prm2 AS Func_Calculated;
GO

--This would be your simple VIEW, consisting of any columns you can easily get
SELECT *
FROM dbo.TestTable
--This is how you join the "buiness logic" to your view
CROSS APPLY dbo.TestFunc(TestTable.Col1,TestTable.Col2) AS func

DROP TABLE dbo.TestTable;
GO
DROP FUNCTION dbo.TestFunc;      
GO
于 2015-09-09T14:15:18.800 回答