Вы бы не написали приложение с функциями длиной в 200 строк. Вы бы разложили эти длинные функции на более мелкие функции, каждая из которых несет четко определенную ответственность.
Зачем так писать свой SQL?
Разложите свои запросы так же, как вы разложите свои функции. Это делает их короче, проще, проще для понимания, тестирования и рефакторинга. И это позволяет вам добавлять «прокладки» между ними и «оболочки» вокруг них, как вы это делаете в процедурном коде.
Как ты делаешь это? Превращая каждую важную вещь, которую делает запрос, в представление. Затем вы сочиняете более сложные запросы из этих более простых представлений, так же как вы составляете более сложные функции из более примитивных функций.
И самое замечательное в том, что для большинства композиций представлений вы получите точно такую же производительность от своей СУБД. (Для некоторых вы этого не сделаете; и что? Преждевременная оптимизация - корень всех зол. Сначала кодируйте правильно, а затем оптимизируйте, если вам нужно.)
Вот пример использования нескольких представлений для разложения сложного запроса.
В этом примере, поскольку каждое представление добавляет только одно преобразование, каждое из них может быть независимо протестировано для поиска ошибок, и тесты просты.
Вот базовая таблица в примере:
create table month_value(
eid int not null, month int, year int, value int );
Эта таблица ошибочна, потому что в ней используются два столбца, месяц и год, для представления одного элемента данных, абсолютного месяца. Вот наша спецификация для нового вычисляемого столбца:
Мы сделаем это как линейное преобразование, чтобы оно было таким же, как (год, месяц), и чтобы для любого кортежа (год, месяц) было одно-единственное значение, и все значения были последовательными:
create view cm_absolute_month as
select *, year * 12 + month as absolute_month from month_value;
Теперь то, что нам нужно проверить, заложено в нашей спецификации, а именно, что для любого кортежа (год, месяц) существует один и только один (absolute_month), и что (absolute_month) являются последовательными. Напишем несколько тестов.
Наш тест будет SQL- selectзапросом со следующей структурой: имя теста и оператор case, соединенные вместе. Имя теста - это просто произвольная строка. Оператор case - это просто case whenтестовые операторы then 'passed' else 'failed' end.
Операторы теста будут просто выборками (подзапросами) SQL, которые должны быть истинными для прохождения теста.
Вот наш первый тест:
--a select statement that catenates the test name and the case statement
select concat(
-- the test name
'For every (year, month) there is one and only one (absolute_month): ',
-- the case statement
case when
-- one or more subqueries
-- in this case, an expected value and an actual value
-- that must be equal for the test to pass
( select count(distinct year, month) from month_value)
--expected value,
= ( select count(distinct absolute_month) from cm_absolute_month)
-- actual value
-- the then and else branches of the case statement
then 'passed' else 'failed' end
-- close the concat function and terminate the query
);
-- test result.
Выполнение этого запроса дает следующий результат: For every (year, month) there is one and only one (absolute_month): passed
Пока в month_value достаточно тестовых данных, этот тест работает.
Мы также можем добавить тест на достаточное количество тестовых данных:
select concat( 'Sufficient and sufficiently varied month_value test data: ',
case when
( select count(distinct year, month) from month_value) > 10
and ( select count(distinct year) from month_value) > 3
and ... more tests
then 'passed' else 'failed' end );
Теперь давайте протестируем это последовательно:
select concat( '(absolute_month)s are consecutive: ',
case when ( select count(*) from cm_absolute_month a join cm_absolute_month b
on ( (a.month + 1 = b.month and a.year = b.year)
or (a.month = 12 and b.month = 1 and a.year + 1 = b.year) )
where a.absolute_month + 1 <> b.absolute_month ) = 0
then 'passed' else 'failed' end );
Теперь давайте поместим наши тесты, которые представляют собой просто запросы, в файл и запустим этот сценарий для базы данных. В самом деле, если мы сохраняем наши определения представлений в сценарии (или сценариях, я рекомендую один файл для каждого связанных представлений) для запуска в базе данных, мы можем добавить наши тесты для каждого представления в один и тот же сценарий, чтобы действие (повторное -) создание нашего представления также запускает тесты представления. Таким образом, мы оба получим регрессионные тесты при повторном создании представлений, и, когда создание представления запускается в производственной среде, представление также будет протестировано в производственной среде.