Есть проект, в котором большая часть бизнес-логики реализована в БД (MS SQL) в виде хранимых процедур, DTS-пакетов и т.д. Какие средства и методики лучше использовать для тестирования логики в БД (хранимых процедур, DTS-пакетов и т.д.)?

VO>Есть проект, в котором большая часть бизнес-логики реализована в БД (MS SQL) в виде хранимых процедур, DTS-пакетов и т.д. Какие средства и методики лучше использовать для тестирования логики в БД (хранимых процедур, DTS-пакетов и т.д.)?

имхо лучшая методика тестирования логики в бд —
не помещать логику в бд

Здравствуйте, VikaOleneva, Вы писали:

VO>Есть проект, в котором большая часть бизнес-логики реализована в БД (MS SQL) в виде хранимых процедур, DTS-пакетов и т.д. Какие средства и методики лучше использовать для тестирования логики в БД (хранимых процедур, DTS-пакетов и т.д.)?

На мой взгляд, в этом случае лучше использовать 2 эталонные базы (или больше, в зависимости от источников) с данными: данные до тестирования и данные, которые должны получиться после тестов.
Процесс тестирования будет такой:

1. Готовим тестовые наборы данных и необходимые результаты
   
2. Создаем новую базу и копиркем в нее эталонные данные до тестирования
   
3. Запускаем тест или набор взаимосвязанных тестов
   
4. Проверяем результат тестов с эталонными данными, которые должны получиться
   
5. Выполняем шаги 2-4 для всех тестов

При этом следует помнить, что некоторые тесты могут влиять друг на друга (вернее на результат), а некоторые не должны влиять.

Оптимально вводить такое тестирование с самого начала разработки, т.к. описать тестовые данные по мере создания системы намного проще, нежели проделать то же самое после большого количества выполненной работы.

Идея навеяна TDD (Test Driven Development)

Здравствуйте, VikaOleneva, Вы писали:

VO>Есть проект, в котором большая часть бизнес-логики реализована в БД (MS SQL) в виде хранимых процедур, DTS-пакетов и т.д. Какие средства и методики лучше использовать для тестирования логики в БД (хранимых процедур, DTS-пакетов и т.д.)?

1. где то на MSDN была статья на эту тему
2. я обычно тещю используя связку osql/fc из bat-файлов (хотя можно и *.js использовать)..
— то есть поднимаю тестовые данные,
— запускаю тестовые функции из скрипта
(результат выкидываю в тестовый файл)
— сравниваю полученный файл результата

что то вроде:

@echo off

set user=%1
set password=%2
set test_name=%3
set test_title=%4

set path_to_osql=C:\Program Files\Microsoft SQL Server\80\Tools\Binn

"%path_to_osql%\osql.exe" -U %user% -P %password% -i t\%test_name%.test.sql -n -b -w 10000 > r\%test_name%.result

fc /N /L r\%test_name%.result.etalon r\%test_name%.result > r\%test_name%.diff

set err=%ERRORLEVEL%

call print_result_message.bat %err% 0 %test_title%

if %err% NEQ 0 goto end

del r\%test_name%.result
del r\%test_name%.diff

:end

Здравствуйте, OnThink, Вы писали:

VO>>Есть проект, в котором большая часть бизнес-логики реализована в БД (MS SQL) в виде хранимых процедур, DTS-пакетов и т.д. Какие средства и методики лучше использовать для тестирования логики в БД (хранимых процедур, DTS-пакетов и т.д.)?

OT>имхо лучшая методика тестирования логики в бд -
OT>не помещать логику в бд

Не согласен — бизнес логика как раз и должна сидеть в бд. Надо только правильно все сделать, чтобы тестировать можно было. Например, как здесь

Автор: Sshur
Дата: 05.03.05

Здравствуйте, VikaOleneva, Вы писали:

VO>Есть проект, в котором большая часть бизнес-логики реализована в БД (MS SQL) в виде хранимых процедур, DTS-пакетов и т.д. Какие средства и методики лучше использовать для тестирования логики в БД (хранимых процедур, DTS-пакетов и т.д.)?


Это все есть сложный и неоднократно поднимавшийся вопрос .

Мое ИМХО — что всю логику надо писать независимой от данных, то есть вызывать функции или процедуры с некоторыми параметрами, которые важны для этой процедуры. Посчитанные результаты возвращать тоже через параметры или возвращаемые значения и сохранять в таблицах где-то в другом месте. Это позволит легко тестировать эти процедуры без модификации данных в БД (возможно, в них будут обращения к некоторым статичным справочникам, но не более того). Например, логику работы биллинговой системы такая схема тестирования покрывает.

Что делать с запросами, которые должны модифицировать большое количество данных — не знаю, наверно как-то разбивать на части. . Если кто подскажет, буду рад.

S> Не согласен — бизнес логика как раз и должна сидеть в бд. Надо только правильно все сделать, чтобы тестировать можно было. Например, как здесь

Автор: Sshur
Дата: 05.03.05

Логику в БД можно помещать, но имхо не стоит
И причина не только в тестировании. (К тестированию логики в БД можно относиться, как к тестированию приватных методов. Т. е. не важно что выдаёт приватный метод, если эффект открытого метода соответствует требованиям.)

Гораздо важнее то, что логику в БД сложнее сопровождать.
Вот когда будет объектно-ориентированный уровень хранимых процедур с поддержкой всех вкусностей обычного программирования, тогда вопрос может быть разрешён и в эту сторону.

Третья причина — чёткоё разделение на слои: когда логика доступа к данным отделена от бизнес-логики, достигается более высокий уровень абстракции бизнес-логики, что есть абсолютное ДОБРО.

Здравствуйте, OnThink, Вы писали:

S>> Не согласен — бизнес логика как раз и должна сидеть в бд. Надо только правильно все сделать, чтобы тестировать можно было. Например, как здесь

Автор: Sshur
Дата: 05.03.05

OT>Логику в БД можно помещать, но имхо не стоит
OT>И причина не только в тестировании. (К тестированию логики в БД можно относиться, как к тестированию приватных методов. Т. е. не важно что выдаёт приватный метод, если эффект открытого метода соответствует требованиям.)

OT>Гораздо важнее то, что логику в БД сложнее сопровождать.

Тут не согласен. Да, хороший ОО-код гораздо проще сопровождать чем процедурный, но будет ли это главным фактором — зависит от приложения. Мне очень много сил и времени сэкономила возможность легко и непринужденно не прерывая работы вносить изменения в хранимые процедуры. Если бы тот же код сидел в клиентском приложении, то пришлось бы одновременно обновлять десятка 2 рабочих мест, что гораздо сложнее. Ну и к SQL можно из любого места подключиться.. Короче это перевесило, благо сама логика не слишком сложная. ну и правильный дизайн в процедурном программирвании никто не отменял

OT>Вот когда будет объектно-ориентированный уровень хранимых процедур с поддержкой всех вкусностей обычного программирования, тогда вопрос может быть разрешён и в эту сторону.

OT>Третья причина — чёткоё разделение на слои: когда логика доступа к данным отделена от бизнес-логики, достигается более высокий уровень абстракции бизнес-логики, что есть абсолютное ДОБРО.


Вот тут согласен, но до этого еще не скоро. Думал в MSSQL 2005 будет полноценная поддержка .NET, ан нет .

Тут кстати еще проблема в том, что в любом случае будет стык реляционной базы данных и ОО модели приложения. Наверно все будет так красиво, как Вы описали, только в случае ООБД, но там наверняка будут свои проблемы.

Здравствуйте, OnThink, Вы писали:

OT>Логику в БД можно помещать, но имхо не стоит
Все зависит от выполняемых задач.

OT>И причина не только в тестировании. (К тестированию логики в БД можно относиться, как к тестированию приватных методов. Т. е. не важно что выдаёт приватный метод, если эффект открытого метода соответствует требованиям.)
Причем здесь приватные методы и ассоциации с ними? Логика, помещенная в БД, равноценна открытому методу у которого есть четко определенный вход (параметры, таблицы) и четко определенный выход (параметры, таблицы).

OT>Гораздо важнее то, что логику в БД сложнее сопровождать.
Кто сказал? Все зависит от уровня заточки рук DBA

OT>Вот когда будет объектно-ориентированный уровень хранимых процедур с поддержкой всех вкусностей обычного программирования, тогда вопрос может быть разрешён и в эту сторону.
О чем это?.. Реляционная модель и объектная модель предназначены для разного. Не стоит смешивать эти понятия. Обработка больших объемов связанных данных лучше всего делается именно в БД.

OT>Третья причина — чёткоё разделение на слои: когда логика доступа к данным отделена от бизнес-логики, достигается более высокий уровень абстракции бизнес-логики, что есть абсолютное ДОБРО.
Очень спорно. Обычно делается компромис между "уровнем абстракции бизнес-логики" и производительностью системы. Если производительность не так важна и необходима поддержка большого количества разнородных БД, то Ваш подход может быть оправдан. В остальных случаях часть БЛ может быть реализована в БД, да и под каждую БД пишется свой адаптер, который необходимо оптимизировать.

Для общего развития данного направления можно почитать эту статью (к нашему разговору применима третья часть статьи).

ура
будем дискутировать

S>Все зависит от выполняемых задач.
согласен

S>Причем здесь приватные методы и ассоциации с ними? Логика, помещенная в БД, равноценна открытому методу у которого есть четко определенный вход (параметры, таблицы) и четко определенный выход (параметры, таблицы).

Приватные методы при том, что бизнес-логика при правильном подходе к абстракции должна полностью инкапсулировать операции с данными, а как нам предоставляет процедуры БД — это уже дело десятое.

S>Кто сказал? Все зависит от уровня заточки рук DBA

Когда это ДБА сопровождал бизнес-логику? Ему хоть под х.., хоть под стамеску руки заточи — это положение дел с поддержкой кода хранимых процедур не изменит.

OT>>Вот когда будет объектно-ориентированный уровень хранимых процедур с поддержкой всех вкусностей обычного программирования, тогда вопрос может быть разрешён и в эту сторону.
S> О чем это?.. Реляционная модель и объектная модель предназначены для разного. Не стоит смешивать эти понятия. Обработка больших объемов связанных данных лучше всего делается именно в БД.

Вот именно. Не надо смешивать. Бизнес-логика в сегодняшнем мире практически всегда реализуется через ООП. Это на порядок снижает ошибки и улучшает поддержку кода.

S>Очень спорно. Обычно делается компромис между "уровнем абстракции бизнес-логики" и производительностью системы. Если производительность не так важна и необходима поддержка большого количества разнородных БД, то Ваш подход может быть оправдан. В остальных случаях часть БЛ может быть реализована в БД, да и под каждую БД пишется свой адаптер, который необходимо оптимизировать.

Проснитесь, товарищ! Производительность в наше время уже давно отошла даже не на второй план. Эффективность во всём мире меряют затраченными средствами. И если дешевле купить дополнительное оборудование, вместо того чтобы кормить дополнительных работников, заказчик так и сделает. А плохое сопровождение и дополнительные ошибки — это как раз дополнительные человеко-часы.

Здравствуйте, OnThink, Вы писали:

OT>ура
OT>будем дискутировать
Ну что ж... Война так война...

S>>Причем здесь приватные методы и ассоциации с ними? Логика, помещенная в БД, равноценна открытому методу у которого есть четко определенный вход (параметры, таблицы) и четко определенный выход (параметры, таблицы).

OT>Приватные методы при том, что бизнес-логика при правильном подходе к абстракции должна полностью инкапсулировать операции с данными, а как нам предоставляет процедуры БД — это уже дело десятое.
Но никто не мешает БЛ выступать в роли прокси (в некоторых или во всех случаях). ну а тестирование БЛ в БД можно обеспечить так же, как и для БЛ в программе.

S>>Кто сказал? Все зависит от уровня заточки рук DBA
OT>Когда это ДБА сопровождал бизнес-логику? Ему хоть под х.., хоть под стамеску руки заточи — это положение дел с поддержкой кода хранимых процедур не изменит.
Да, пишут программисты, но DBA (или сам программист, если он обладает уровнем вменяемости DBA) делает оценку результата и производит необходимые модификации. Этот процесс не раз обсуждался в форумах RSDN.

OT>>>Вот когда будет объектно-ориентированный уровень хранимых процедур с поддержкой всех вкусностей обычного программирования, тогда вопрос может быть разрешён и в эту сторону.
S>> О чем это?.. Реляционная модель и объектная модель предназначены для разного. Не стоит смешивать эти понятия. Обработка больших объемов связанных данных лучше всего делается именно в БД.

OT>Вот именно. Не надо смешивать. Бизнес-логика в сегодняшнем мире практически всегда реализуется через ООП. Это на порядок снижает ошибки и улучшает поддержку кода.
Buggy code можно писать на чем угодно — все зависит от уровня программиста. Не следует считать, что ООП — это панацея. Я не утверждаю, что всю БЛ необходимо писать на уровне БД. Самое главное — это найти золотую середину, когда БЛ в БД будет выполнять тот набор операций, которые лучше всего выполняются именно сервером БД, а не сервером приложений.

S>>Очень спорно. Обычно делается компромис между "уровнем абстракции бизнес-логики" и производительностью системы. Если производительность не так важна и необходима поддержка большого количества разнородных БД, то Ваш подход может быть оправдан. В остальных случаях часть БЛ может быть реализована в БД, да и под каждую БД пишется свой адаптер, который необходимо оптимизировать.

OT>Проснитесь, товарищ!
Не сплю я, не сплю! Может мы находимся на разных уровнях и поэтому не понимаем друг друга?

OT>Производительность в наше время уже давно отошла даже не на второй план.
Неповоротливого монстра никто не будет покупать. Остальные доводы см. ниже.

OT>Эффективность во всём мире меряют затраченными средствами. И если дешевле купить дополнительное оборудование, вместо того чтобы кормить дополнительных работников, заказчик так и сделает.
Отчасти согласен. Но следует заметить, что профессионал в своем деле имеет наивысший КПД. Если команда состоит из профессионалов, то эффективность будет измеряться в первую очередь в КПД команды. Ведь при создании и внедрении именно команда профессионалов оценивает технические ресурсы, необходимые под проект, и определяют оптимальную программно-аппаратную конфигурацию с необходимой производительностью. Иногда (в рамках enterprise) намного эффективнее нанять профессионалов с целью добиться максимальной производительности, не вкладывая намного большие деньги в аппаратную часть, производительность которой очень часто не прямо пропорциональна стоимости.

OT>А плохое сопровождение и дополнительные ошибки — это как раз дополнительные человеко-часы.
Отсюда вывод: надо брать профессионалов. Статистика показывает, что результат их работы значительно лучше, что снижает затраты на разработку и сопровождение.

S>Но никто не мешает БЛ выступать в роли прокси (в некоторых или во всех случаях). ну а тестирование БЛ в БД можно обеспечить так же, как и для БЛ в программе.

Немного сложнее

OT>>Когда это ДБА сопровождал бизнес-логику? Ему хоть под х.., хоть под стамеску руки заточи — это положение дел с поддержкой кода хранимых процедур не изменит.
S>Да, пишут программисты, но DBA (или сам программист, если он обладает уровнем вменяемости DBA) делает оценку результата и производит необходимые модификации. Этот процесс не раз обсуждался в форумах RSDN.

ИМХО это называется не сопровождением БЛ, а оптимизацией БД

S>Buggy code можно писать на чем угодно — все зависит от уровня программиста. Не следует считать, что ООП — это панацея.

Не панацея, но когда можно уменьшить вероятность ошибок, надо этим заниматься, а не расстреливать команду или наборот кивать на судьбу.

S>Я не утверждаю, что всю БЛ необходимо писать на уровне БД. Самое главное — это найти золотую середину, когда БЛ в БД будет выполнять тот набор операций, которые лучше всего выполняются именно сервером БД, а не сервером приложений.

Этот вариант с некоторыми допущениями проходит для малых приложений. Для больших проектов необходимо разделение абстракций на слои.

S>>>Очень спорно. Обычно делается компромис между "уровнем абстракции бизнес-логики" и производительностью системы. Если производительность не так важна и необходима поддержка большого количества разнородных БД, то Ваш подход может быть оправдан. В остальных случаях часть БЛ может быть реализована в БД, да и под каждую БД пишется свой адаптер, который необходимо оптимизировать.

OT>>Проснитесь, товарищ!
S>Не сплю я, не сплю! Может мы находимся на разных уровнях и поэтому не понимаем друг друга?

OT>>Производительность в наше время уже давно отошла даже не на второй план.
S>Неповоротливого монстра никто не будет покупать. Остальные доводы см. ниже.

Не будем утрировать. Однако в последнее время довольно малый процент программ требует оптимизации кода, и тем более мизерный процент — жертвы архитектуры в пользу производительности.

S>Отчасти согласен. Но следует заметить, что профессионал в своем деле имеет наивысший КПД. Если команда состоит из профессионалов, то эффективность будет измеряться в первую очередь в КПД команды. Ведь при создании и внедрении именно команда профессионалов оценивает технические ресурсы, необходимые под проект, и определяют оптимальную программно-аппаратную конфигурацию с необходимой производительностью. Иногда (в рамках enterprise) намного эффективнее нанять профессионалов с целью добиться максимальной производительности, не вкладывая намного большие деньги в аппаратную часть, производительность которой очень часто не прямо пропорциональна стоимости.

Согласен. И это тем более важно, потому что такие профессионалы не дадут вам угробить архитектуру приложения

OT>>А плохое сопровождение и дополнительные ошибки — это как раз дополнительные человеко-часы.
S>Отсюда вывод: надо брать профессионалов. Статистика показывает, что результат их работы значительно лучше, что снижает затраты на разработку и сопровождение.

Все делают ошибки. Кто это понимает — добивается успеха.

Здравствуйте, OnThink, Вы писали:

S>>Да, пишут программисты, но DBA (или сам программист, если он обладает уровнем вменяемости DBA) делает оценку результата и производит необходимые модификации. Этот процесс не раз обсуждался в форумах RSDN.
OT>ИМХО это называется не сопровождением БЛ, а оптимизацией БД
Нет, я имел ввиду именно сопровождение (изменение объектов БД), а не оптимизацию. Несколько нечетко выразил мысль

S>>Я не утверждаю, что всю БЛ необходимо писать на уровне БД. Самое главное — это найти золотую середину, когда БЛ в БД будет выполнять тот набор операций, которые лучше всего выполняются именно сервером БД, а не сервером приложений.

OT>Этот вариант с некоторыми допущениями проходит для малых приложений. Для больших проектов необходимо разделение абстракций на слои.
Почему же для малых? Потенциально для всех. Про отсутствие слоев тут никто не говорит. Кто мешает сделать Workflow layer над BLL или разделить BLL на несколько? Я говорю именно о конкретных местах, которые легче, проще и быстрее (в том числе и по производительности) разместить и обрабатывать в БД.
В противном случае, БД становится только хранилищем информации, а там еще так много интересного.

OT>>>Производительность в наше время уже давно отошла даже не на второй план.
S>>Неповоротливого монстра никто не будет покупать. Остальные доводы см. ниже.

OT>Не будем утрировать. Однако в последнее время довольно малый процент программ требует оптимизации кода, и тем более мизерный процент — жертвы архитектуры в пользу производительности.
Обычно архитектура строится с учетом производительности. Большинство команд имеют четкие представления об архитектуре приложений и некоторые рабочие шаблоны, которые проверены на практике. Думаю, что не стоит отделять эти два понятия друг от друга (архитектура и производительность).

Здравствуйте, stasukas, Вы писали:

OT>>Гораздо важнее то, что логику в БД сложнее сопровождать.
S>Кто сказал? Все зависит от уровня заточки рук DBA

Очень смелое заявление в отрыве от конкретной СУБД

Как раз минус использования логики в БД — это сложность ее тестирования.
Для кода разработаны методики и средства тестирования, позволяющие практически исключить ошибки.
Для процедур СУБД таких средств нет. Соответсвенно, вероятность ошибки сильно возрастает (либо возрастает время и сложность проекта, что в итоге может привести к его краху).
А стоимостьодной ошибки может быть слишком велика для пользователя вашего ПО.

К тому же не все СУБД поддерживают изменение логики без прерывания работы клиентов, соотвественно цена исправления одной даже мелкой и неведущей к большим проблемам ошибки тоже может быть крайне велика.

Использовать бизнес-логику в БД можно и нужно, но надо знать меру и подводные камни каждого инструмента — в данном случае СУБД.

Здравствуйте, kavlad, Вы писали:

OT>>>Гораздо важнее то, что логику в БД сложнее сопровождать.
S>>Кто сказал? Все зависит от уровня заточки рук DBA
Администратора Access за DBA предлагаю не считать

K>Очень смелое заявление в отрыве от конкретной СУБД
В любом случае, основания для таких заявлений у меня есть. Да и по теме идет как минимум обсуждение MS SQL.

K>Как раз минус использования логики в БД — это сложность ее тестирования.
Не согласен. Есть специфика, конечно, но не настолько это и сложно. Опять же, все зависит от того человека, который программирует, вернее, от его уровня.

K>Для кода разработаны методики и средства тестирования, позволяющие практически исключить ошибки.
K>Для процедур СУБД таких средств нет. Соответсвенно, вероятность ошибки сильно возрастает (либо возрастает время и сложность проекта, что в итоге может привести к его краху).
Для БД используются ровно те же методики тестирования, что и для программ. Ну а средства тестирования можно использовать все те же (*Unit) или специфические. Логика тестирования может находиться как в БД, так и в программе тестирования.

K>А стоимостьодной ошибки может быть слишком велика для пользователя вашего ПО.
Как и для любой другой системы.

K>К тому же не все СУБД поддерживают изменение логики без прерывания работы клиентов, соотвественно цена исправления одной даже мелкой и неведущей к большим проблемам ошибки тоже может быть крайне велика.
Обычно хранимую процедуру сожно изменить без особых проблем. А вот с серверами приложений могут возникнуть проблемы похуже этой, т.к. в большинстве случаев его необходимо останавливать, накатывать обновления и запускать заново.
В любом случае, best practice говорит о том, что обновление системы необходимо производить в то время, когда к ней нет обращений, или она имеет наименьшую нагрузку, совместно с выделением на это времени технического обслуживания системы.

K>Использовать бизнес-логику в БД можно и нужно, но надо знать меру и подводные камни каждого инструмента — в данном случае СУБД.
Согласен.

Здравствуйте, OnThink, Вы писали:

S>> Не согласен — бизнес логика как раз и должна сидеть в бд. Надо только правильно все сделать, чтобы тестировать можно было. Например, как здесь

Автор: Sshur
Дата: 05.03.05

OT>Логику в БД можно помещать, но имхо не стоит
OT>И причина не только в тестировании. (К тестированию логики в БД можно относиться, как к тестированию приватных методов. Т. е. не важно что выдаёт приватный метод, если эффект открытого метода соответствует требованиям.)

OT>Гораздо важнее то, что логику в БД сложнее сопровождать.
OT>Вот когда будет объектно-ориентированный уровень хранимых процедур с поддержкой всех вкусностей обычного программирования, тогда вопрос может быть разрешён и в эту сторону.

OT>Третья причина — чёткоё разделение на слои: когда логика доступа к данным отделена от бизнес-логики, достигается более высокий уровень абстракции бизнес-логики, что есть абсолютное ДОБРО.

Уважаемый теоретик, не стесняйтесь в жизненных примерах о том как НАДО делать

Tom>Уважаемый теоретик, не стесняйтесь в жизненных примерах о том как НАДО делать

примеры Вам предоставит жизнь. Или старшие товарищи. Я не могу. Конфиденциальная информация.