A (T) Sql-представление, содержащее слишком много бизнес-логики

Question

У меня есть представление TSQL. Помимо нескольких столбцов это довольно просто, потому что он просто делает несколько объединений, а затем склеивает все вместе, чтобы представить красивый вид, каким он должен быть. Тем не менее, несколько столбцов, которые не так просты, очень сильно расширяют код представления, теперь возникают новые требования, что делает недействительными бизнес-логику сложных столбцов.

Не вдаваясь слишком много в подробности, есть таблица в моей базе данных:

tblEmployment 

Это состоит из рядов «заработкам». Каждый раз, когда любая из столбцов в строке, для данного изменения занятости (скажем, employmentTitle изменения), то тока строки вставляется в другую таблицу tblEmploymentHistory и строк в tblEmployment изменяется таким образом, он содержит новейшую employmentTitle.

По существу, что делает вид, заключается в том, что он пытается присоединиться к tblEmployment на tblEmploymentHistory с уникальным EmploymentIdentifier, что имеет смысл.

Более сложный столбец в представлении попытается вычислить число (elapsedTime для каждой строки), выполнив различные вычисления из строк, которые он объединил (т. Е. От tblEmployment and tblEmploymentHistory). Чтобы получить прошедшее время, он выполняет вычисления на основе продиктованной бизнес-логики, например. только конкретные столбцы datetime в таблице предыстории должны подсчитываться в течение всего прошедшего времени, и это должно быть сделано только в том случае, если другие столбцы в этой строке установлены на определенные значения и т. д.

Теперь, когда появились новые требования, бизнес-логика сложнее, чем раньше. Мне сложно расширить представление, включив его, поскольку оно становится очень грязным, и я чувствую, что это можно сделать гораздо более структурированным на прикладном уровне, где также находится остальная бизнес-логика!

Правильно ли это отменить просмотр и вместо этого переместить его на прикладной уровень моего приложения? Очевидно, что преимущество в том, что это быстро, и выполнение вычислений в коде для примерно 100 000 строк займет некоторое время. Тем не менее, его можно оптимизировать, отфильтровывая строки, чтобы сделать число около 10.000.

Что такое «стандартный» и самый чистый способ решения этой проблемы?

Answer 1

Ответ зависит от нескольких вещей. Во-первых, убедитесь, что база данных работает на основе набора. Если вы начинаете получать курсоры (вообще говоря) или какой-то цикл, вам лучше разместить это в приложении. Таким образом, реляционные базы данных неэффективны. Еще одна вещь, которую я бы рассмотрел, - это стандарт для среды, в которой вы работаете? Другие вещи поддерживаются в БД, как это, где вы находитесь? Если это так, вы можете остаться последовательным.

В конце концов, все, что возвращает эти результаты наиболее эффективно и не влияет на другие запросы, должно быть ответом.

Answer 2

Как и было обещано, я приведу вам пример подхода 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