|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Victor Metelitsa 2:5020/400 14 Jan 2002 18:19:24
To : All
Subject : в чем зло хранимых проце дур?
--------------------------------------------------------------------------------
Во-первых, я считаю их злом из "педагогических" соображений. Реляционка
- это ведь про множества записей и операции над множествами? А некие
товарищи (не буду говорить, кто... ! да я даже в книжке по Oracle
примеры такого кода видел, якобы учебного) обращаются с реляционкой, как
с Клиппером, даже когда убогие возможности "их" SQL позволяют без этого
обойтись. Рекорд (в моих глазах) поставил некий крутой спец по ораклу,
который и количество записей в выборке так считает - открыл курсор,
обнулил счетчик, и вперед по записям, накручивая счетчик!
Во-вторых, всякие сложные вычисления. Здесь - вопрос веры. Я верю, что
немыслимо закрученные UPDATE и т.п. (изредка демонстрируемые мне) - это
всего лишь результат неправильной постановки задачи. Доказать я это не
могу, потому что для этого придется в каждую задачу вникать, а это
немыслимо. Hо я в это верю. Когда-то я в SU.DBMS.SQL продемонстрировал
DB2-шный запрос немыслимой величины, а Румянцев по этому или подобному
поводу сказал, что это результат плохой схемы данных. Когда я
познакомился с TOPLink'ом и ее (схему) переосмыслил, я понял/решил, что
он был прав.
Контрпример из IBM-овской поставки - нахождение медианы выборки.
Действительно, нет способа ее вычислить, кроме как просканировать
выборку до середины, и не тянуть же ее на клиента? Hо - кому она нужна,
медиана?
Третье - построение изощренных схем проверок бизнес-правил и секьюрити.
Hо SP для этого не обязательны (на DB2, понятно).
Четвертое - псевдо-ОО-подход, инкапсуляция etc. У меня к этому
отношение, как к тому же псевдо-ОО на plain C. Там теоретически тоже
можно этим заниматься, делать объекты через структуры и указатели на
функции, только ведь это чудовищное уродство. А в случае СУБД - в десять
раз уродливее. Чем брать суррогат, не лучше ли взять натуральный продукт?
Пятое - раздувание кода. Если программёрам платят построчно, это для них
достоинство, но...
***
"правильный подход по ВВМ".
Я предпочитаю минимизировать усилия. Скажем, для настройки СУБД или
создания индексов для запросов я прибегаю к "визардам".
Hо, как правило, и SQL-запросов не пишу. Я когда-то приводил примеры
работы с TOPLink'ом, приведу еще. Hапример, пусть объект employee имеет
атрибут
lname со значением 'Иванов', session - коннект с базой данных.
"1" session beginUnitOfWork.
"2" session registerObject: employee.
"3" employee lname: 'Петров'.
"4" session beginUnitOfWork.
"5" session registerObject: employee.
"6" employee lname: 'Сидоров'.
"7" session rollbackUnitOfWork.
"8" session commitUnitOfWork.
Пример демонстрирует вложенные транзакции. В двойных кавычках -
комментарий (я перенумеровал строки для наглядности). После
registerObject: система отслеживает изменения. Когда в 7-й строке
произошел rollback, фамилия сотрудника автоматически вернулась к
прежнему значению ('Петров'), присвоенному в 3-й строке. Когда в 8-й
строке произошел commitUnitOfWork, если эта единица работы не заключена
в какую-то другую, TOPLink сгенерировал SQL-выражение (наподобие UPDATE
EMPLOYEE SET lname='Петров' WHERE employeeId=что-то-там) и выполнил его,
затем COMMIT. TOPLink имеет много возможностей и умеет генерировать
очень сложные запросы, а также берет на себя заботу об identity-полях
(причем эмулируя их там, где их нет).
Hа SP так просто не получится (мягко говоря).
Далее,
у меня такой код зашит в клиентских программах, их обновления
автоматически доставляются на рабочее место (а можно было использовать
shared resource), так что рассинхронизации нет. Более правильно было бы,
чтобы такой код был загружен в единственном экземпляре, т.е. трехзвенка;
а если application server расположен, скажем, там же, где и
SQL-сервер, то и медианы можно было бы находить без напряга, сетевого
трафика нет; увы, у меня пока не так. Еще лучше было бы выкинуть
SQL-сервер на помойку и пользоваться чистым GemStone/S, но это слишком
дорого (особенно, учитывая, что спиратить его, в отличие от
DB2/Oracle/etc, практически невозможно).
--
Отправлено через сервер Talk.Ru - http://www.talk.ru
--- ifmail v.2.15dev5
* Origin: Talk.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
