Что лучше - SELECT'ы прямо из кода или вызов хранимых процедур?

rgb-dart
Дата: 27.02.2006 20:02:15
Сформулирую вопрос по-четче.
Допустим, есть клиент-серверное приложение (WinForms). Для получения данных из БД и для модификации данных в БД можно у SqlCommand (например)
А) В CommandText'е прямо писать "Select.... Update... Delete" и т.д.
Б) В CommandText'е писать имя хранимой процедуры, в которой реализованы все эти select, delete и т.п.

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

Интересуют аргументы в пользу пункта А.
В пользу пункта Б приведу ряд своих аргументов, надеюсь услышать конструктивную критику. Вот они:
1) Хранимые процедуры позволяют абстрагироваться от структуры БД, от названий колонок и таблиц. В случае если потребуется переименовать какое-то поле, то не придется лазить по всему коду выиискивая где используется это поле, а просто через Dependency поднять хранимые процедуры использующие таблицу.
2) Хранимые процедуры легче отладить, чем отлаживать код приложения, делающий "сырой запрос". Процедуру я могу запустить в QueryAnalyser, и сразу убедится - хотя бы работает ли она? Если запрос сырой в коде, то остается только ловить SqlException в процессе функционального тестирования.
3) Если в нескольких местах программы требуется выполнить одинаковый запрос, то лучше вызвать в обоих местах хранимую процедуру, чем дублировать "сырой" sql-текст. (Конечно, проблема решается и без процедур, если есть "слой доступа к данным" в приложении, но мне с проектом не повезло и тут все запросы делаются прямо из форм - тяжелое наследие предшественников)
4) ?


В принципе, этот топик чем-то напоминает тему для Священной Войны.
Да простят меня модераторы. =(

З.Ы. Буду признателен за ссылки на статьи "умных людей" на эту тему.
Шайтан
Дата: 28.02.2006 09:50:48
4) использование хранимок скрывает структуру данных

по пункту "А" у меня аргументов в "+" нет :)

Шайтан
Sa
Дата: 28.02.2006 10:06:38

rgb-dart

Интересуют аргументы в пользу пункта А.

Очень хилые в пользу ХП у Вас аргументы.
ИМХО:
1) Инкапсулировать структуру БД, лучше в отдельном слое программы. Можно вообще создать идеальную БД на базе DataSet и собирать данные из разрозненных БД информационной сети предприятия.
2) Что мешает отладить теже запросы в QA?
3) То что запросы делаются прямо из форм, не значит, что CommandText необходимо хранить там же, да и комманды можно получать из другого места.

ИМХО главный аргумент в пользу ХП - это производительность их выполнения, остальное сложно назвать плюсом. Так же как назвать языки программирования ХП - языками программирования.

Что касается пункта А.
То один из плюсов - возможность создания программы одновременно поддерживающей несколько поставщиков СУБД - MS и Oracle без жесткой привязки к Transact SQL и PL SQL, например. Если есть слой данных, то можно легко перейти на другую СУБД, переписав этот слой.
....

rgb-dart

В принципе, этот топик чем-то напоминает тему для Священной Войны.
Да простят меня модераторы. =(

Не простим :-)

P.S. Все относительно конечно, надо смотреть конкретно задачу, другие условия и.т.д.

uid = Sa

Posted via ActualForum NNTP Server 1.3

rgb-dart
Дата: 28.02.2006 10:46:04
Sa

Очень хилые в пользу ХП у Вас аргументы.
ИМХО:
1) Инкапсулировать структуру БД, лучше в отдельном слое программы. Можно вообще создать идеальную БД на базе DataSet и собирать данные из разрозненных БД информационной сети предприятия.
2) Что мешает отладить теже запросы в QA?
3) То что запросы делаются прямо из форм, не значит, что CommandText необходимо хранить там же, да и комманды можно получать из другого места.


Спасибо за контраргументы, однако:
1) Я согласен, что инкапсулировать структуру БД лучше в отдельном слое (в умных книжках его так и называют Data Access Layer), но реалии проекта таковы, что этого слоя нет и в помине. В процессе рефакторинга тяжелого наследия я этот слой создаю, но вместе с тем, я меняю прямые селекты на вызовы хранимых процедур. Проблема у меня возникла когда "начальник" попросил меня обосновать необходимость такого рода "переделок".
2) Если запрос параметризированный, то придется самому писать всякие Declare и Set параметров для отладки. В QA можно через object browser делать open у процедуры и задавать параметры. То есть, банально - хранимые процедуры удобней отлаживать.
3) Да, да. Это все к вопросу об организации слоя доступа к данным. Хорошо, аргумент снимается.

Sa

Что касается пункта А.
То один из плюсов - возможность создания программы одновременно поддерживающей несколько поставщиков СУБД - MS и Oracle без жесткой привязки к Transact SQL и PL SQL, например. Если есть слой данных, то можно легко перейти на другую СУБД, переписав этот слой.

А если слоя нет и в помине? Из форм прямо вызываются всякие SqlCommand и иже с ними. При переходе на новую СУБД по-любому придется сильно править и исходные коды и тексты sql-запросов. Синтаксис PL\SQL, на сколько я знаю, местами сильно отличается от TSQL (case'ы, top'ы). Да и вообще, после небольшого опыта работы с ораклом, у меня сложилось впечателение что для этих СУБД различается сам подход к написанию серверной логики. PL\SQL более "процедурный" язык. Реализовывать бизнес-логику на Оракле гораздо проще (имхо) чем на Сиквеле. Это мое имхо. Поэтому, я не думаю, что отказ от использования хранимых процедур серьезно упростит портирование системы на новую СУБД.

Вопрос\просьба в догонку. У кого-нибудь под рукой есть ссылки на статьи "авторитетных" авторов утверждающие что "слой доступа к данным - это хорошо"? То что это хорошо, я и так интуитивно понимаю (и делаю), но особенности менталитета начальника заставляют прибегать к авторитету сторонних специалистов.
Sa
Дата: 28.02.2006 11:46:21

rgb-dart

А если слоя нет и в помине? Из форм прямо вызываются всякие SqlCommand и иже с ними.

Против лома нет приема. Изначально надо было отрывать руки, тому кто программу проектировал.

Что касается PL/SQL и других процедурных языков. То никакой структурный язык не сравниться с ОО языком программирования. Вы попробуйте, написать на подобном языке более менее сложную логику работы с данными, а затем через два года вернитесь к этому коду.

rgb-dart

У кого-нибудь под рукой есть ссылки на статьи "авторитетных" авторов утверждающие что "слой доступа к данным - это хорошо"?

Пожалуйста, здесь же, и другие мысли по сабжу:

Оригинал (на английском):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

Тоже самое на русском (перевод):
http://www.gotdotnet.ru/LearnDotNet/NETFramework/592.aspx

uid = Sa

Posted via ActualForum NNTP Server 1.3

rgb-dart
Дата: 28.02.2006 18:25:54
Sa

rgb-dart

А если слоя нет и в помине? Из форм прямо вызываются всякие SqlCommand и иже с ними.

Против лома нет приема. Изначально надо было отрывать руки, тому кто программу проектировал.

Поздно отрывать, они уже успели уволится.

Спасибо за ссылки - то что нужно! :)
Flare
Дата: 01.03.2006 01:40:31
rgb-dart
А если слоя нет и в помине? Из форм прямо вызываются всякие SqlCommand и иже с ними.
Вот это чудо-"erp" на фокспро, например, так и работает.