 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Victor Metelitsa 2:5020/400 23 Jan 2002 12:18:01 To : Sergey Pratch Subject : Re: Hа: в чем зло хранимых проце дур-2 -------------------------------------------------------------------------------- Sergey Pratch wrote: > Hi! > > "Victor Metelitsa" <vvm@cssc.tat.ru> сообщил/сообщила в новостях следующее: > news:3C4D1F2B.40801@cssc.tat.ru... > >>Когда я говорил о зле хранимых процедур, я имел в уме некую >>"идеализированную" реляционную СУБД. Каковы ее характерные черты? >>Очевидно, например, что результаты выборок должны получаться >>последовательным применением реляционных операций над множествами >>записей. Если же программер вынужден открывать курсоры и ерзать >>вперед-назад по выборке, это, извините, уже Клиппер. Аналогично можно >>сказать о модификациях данных (вставка/обновление/удаление). Беда в том, >>что большинство местных читателей обмануто - они думают, что работают с >>реляционными СУБД, когда на самом деле работают с "полуклиппером" и/или >>делают неадекватные модели данных. >> > > А когда я обсуждал с тобой эту тему, то под ХП понимал два тезиса: > > 1. ХП - это просто поименованые пакеты (или даже одиночный) SQL-оператор. > 2. Задача клиент-серверной технологии: концетрация вычислительных ресурсов в > одном месте и за счет этого более лучшее их использование и планирование > использования. > > > По п.1: от того, что некоему оператору (пакету операторов) имеется > возможность присвоения имени и вызова его по имени, назвать это злом - ну не > то что бы глупость, но ересь точно. И это я могу написать даже без ИМХО! Я же не объявлял злом VIEW. > По п.2: как раз тот факт, что необходимы дополнителные ресурсы на > клиенте для генерация этого оператора, вместо использования такого же, но > поименованого на сервере - уже есть факт децентрализации ресурсов. При этом > стоит заметить, что не такой уж и малой кровью в этом случаем можно > отделатся. Hе говоря о том, что это просто тупое увеличение сетевого > трафика. зачастую очень многие требуемые операторы не такие уж и маленькие > (например у меня, получение остатка по счету на определенную дату - не менее > 25-30 строк, а возвращаемый результат - одна запись, размером не более 20 > байт) и воплне реальна ситуация, когда входящий трафик на сервер легко > превысит исходящий или еще хуже, сравнится с ним. Трафик в локальной сети надо считать не в байтах, а в Ethernet-пакетах. (В WAN своя логика, там напрямую к СУБД вообще стараются не подключаться). Потом, надо еще посмотреть, _что это еще за запросы_ и _какова структура данных_. Из самых свежих примеров - обсуждение вычисления курса доллара в SU.DBMS.DB2. Подписчик держал|держит курсы доллара в таблице (Вариант 1) КУРСЫ1 Курс Дата _____ _________ 30.80 1.01.2002 30.81 5.01.2002 30.82 15.01.2002 (данные "от фонаря"), что означает на самом деле (Вариант 2) КУРСЫ2 Курс HачальнаяДата КонечнаяДата _____ _____________ ____________ 30.80 1.01.2002 4.01.2002 30.81 5.01.2002 10.01.2002 30.82 15.01.2002 конец времен (31.12.9999 - "конец времен" по версии IBM). По первому варианту вычисление курса на произвольную дату представляет значительные трудности. Hо обратите внимание: сами данные записаны "не по-реляционному", они требуют упорядоченности (по дате) и при вычислениях - движения по упорядоченной таблице (что, конечно, делается необязательно курсором; быть может, и MAX ... WHERE). Второй вариант гораздо проще в использовании (и быстрее при исполнении!), типа: SELECT ТОВАРЫ.ЦенаРуб*КУРС2.Курс AS ЦенаВДолларах FROM ТОВАРЫ, КУРС WHERE ТОВАРЫ.ДатаПродажи BETWEEN КУРС2.HачальнаяДата AND КУРС2.КонечнаяДата конечно, появляется необходимость следить (триггерами) за непересечением диапазонов дат и т.п., но это-таки меньшее зло. -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/5364fab5f985.html, оценка из 5, голосов 10
|
|
|