Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

реализация запросов [D7, фб 1,5]

Страницы: 1 2 3 >
stud © (2004-04-21 14:11:00)
интересует мнение по вопросу каким образом лучше реализовывать запросы: с помощью хп на сервере или динамически формировать на клиенте? в чем преимущества и недостатки каждой реализации?
в литературе встречал рекомндацию, что не стоит все запросы реализовывать с помощью хп..

Sergey13 (2004-04-22 11:36:00) [1]
2Курдль © (22.04.04 11:25) [43]
>Меня интересует механизЬм заполнения реф-курсора произвольными записями.
А зачем произвольные записи возвращать рефом? Наколбась чего хочешь на клиенте и радуйся. 8-)

Меня интересует, как с помощью Оракла можно войти в нирвану. Мне это нафиг не надо, но на будущее интересно.

Sergey Masloff (2004-04-22 11:27:00) [2]
Курдль © (22.04.04 11:25) [43]
>Меня интересует механизЬм заполнения реф-курсора произвольными >записями
Не знаю что такое произвольная но всегда можно сделать
select 123 as firstfield, 'str' as secondfield from dual

Курдль (2004-04-22 11:25:00) [3]

> А зачем "иначе, чем select-ом"? К чему ты клонишь то?

Меня интересует механизЬм заполнения реф-курсора произвольными записями. У меня такой нужды пока нет и не было (оракл без проблем кушает и оптимизирует хоть километровые запросы), но на будущее полезно знать.

Sergey13 (2004-04-22 11:21:00) [4]
2Курдль © (22.04.04 10:19) [41]
А зачем "иначе, чем select-ом"? К чему ты клонишь то?

Курдль (2004-04-22 10:19:00) [5]

> Sergey_Masloff (21.04.04 15:56) [26]
> Ну а что ORACLE? В нем как раз очень просто за счет рефкурсоров

А как "наполнить" данными курсор иначе, чем select-ом?

Sergey Masloff (2004-04-21 22:23:00) [6]
Nikolay M. © (21.04.04 18:18) [39]
>Свой и чужой опыт подсказывает, что жить, в принципе, можно :)
Да мой тоже подсказывает что можно ;-) Я ж не панацею а один из вариантов привел ;-)

Навскидку что еще реализовано:
1) Результат запроса "хранится". Срок его жизни задается (по умолчанию до полуночи)
2) Результат запроса можно послать произвольному числу пользователей. То есть я запустил запрос который работал 10 минут потом шлю тебе сообщение - смотри что тут за фигня и посылаю тебе запрос без доп. затрат (в том числе затрат трафика - реально пересылается несколько байт)
3) Можно посмотреть историю своих запросов и повторно выполнить какие-то практически без оверхеда

Но повторяю - это лишь один из вариантов и естественно на все случаи жизни его не распространишь ;-)

Nikolay M. (2004-04-21 18:18:00) [7]

> а почему один отчет- одна хп?

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

> Один отчет-одна ХП не напасешься ХП.

Свой и чужой опыт подсказывает, что жить, в принципе, можно :)

> И ничего, как-то обходимся старыми структурами ;-)

Ясно. На самом деле, то, что это работает - это самый главный аргумент, так что утихаю :)

Sergey_Masloff (2004-04-21 18:13:00) [8]
Nikolay M. © (21.04.04 18:05) [36]
Один отчет-одна ХП не напасешься ХП. Естественно такие отчеты строятся не по оперативной базе. А это - оперативные отборы. Поддерживать как раз не очень сложно, а изменения структуры БД... Не знаю. У нас системе уже с десяток лет никаких изменений структуры БД не было (ну почти не было). Просто хорошо спроектировали в самом начале (я не принимал участия). Система полностью автоматизирует крупную компанию с очень непростым бизнесом. И ничего, как-то обходимся старыми структурами ;-)

stud (2004-04-21 18:11:00) [9]
а почему один отчет- одна хп? одна хп может готовить данные для сколь угодно какого количества отчетов. все в ваших руках. кроме того очень здорово вызывать в одной хп другую и получать практически что угодно. кроме этого изменение хп в большинстве случаев проходит более безболезненно чем замена запросов в приложении

Nikolay M. (2004-04-21 18:05:00) [10]
Аргументы понятны, на словах выглядит красиво.
Но воспринимается пока скептически. Для реализации такой схемы надо строить оболочку вокруг исходных таблиц (где какие данные лежат, как их доставать), которая будет сильно зависеть от структуры БД -> трудность поддержки.
Также мне лично не кажется данный подход более удобным по сравнению с более общепринятым "один отчет - одна ХП", где можно построить оптимальные запросы для каждого отдельно взятого отчета + большая гибкость при изменениях в отчетах и структуре БД.
А уж реализовать историю просмотров можно и массой других способов.

Sergey_Masloff (2004-04-21 17:37:00) [11]
Nikolay M. © (21.04.04 17:08) [34]
Нет не любые. Используется активно в отборах. Там скорость приносится в жертву универсальности и гибкости. Так что замечание 1) справедливо но не критично.

По 2). Не любые НД а НД которые я им даю. Они могут сформировать только сколь угодно сложное ограничение на НД.
Возьмем пример отбора счетов. Наверное в результате отбора юзер желает увидеть только небольшой набор атрибутов - плательщик получатель номер сумма недостающее добавить. Но условия отбора могут варьироваться очень сильно и требовать массы джойнов. Так вот пользователь всегда передает сконкатенированый в строку список параметров а я проходя его в цикле строю запрос произвольной сложности. Ну и возвращаю ему его НД. На самом деле есть там немало хитростей которые объяснять а) долго б) нельзя но поверь с таким подходом можно сделать ОЧЕНЬ гибкую систему (ну например как тебе хранение истории кто и что и когда отбирал. Знаешь, иногда ОЧЕНЬ полезно).

Nikolay M. (2004-04-21 17:08:00) [12]

> Sergey_Masloff (21.04.04 16:26) [33]

Обоснованность такого решения неочевидна (по крайней мере для меня).
1) Запрос в этом случае строится ДИНАМИЧЕСКИ, т.е. теряется прелесть использования построенного плана выполнения запроса.
2) Если с помощью нескольких ХП юзеры могут получить практически любые НД из десятка таблиц, почему бы просто не дать им права на чтение напрямую из таблиц?

Sergey_Masloff (2004-04-21 16:26:00) [13]
Nikolay M. © (21.04.04 16:03) [27]
>Да, если разграничение прав построено на основе оболочки из >процедур вокруг собственно таблиц, то придется даже простейшие >селекты оформлять в виде ХП.
Можно написать несколько универсальных ХП которые принимают строку параметров вида param1=val1;param2=val2 и так далее и на основе строит конкретный текст запроса НА СЕРВЕРЕ и НА СЕРВЕРЕ его же выполняет. То есть пользователь имеет очень большое количество запросов которые реализуют всего несколько ХП. И это не теория - я активно применяю реализацию такого подхода (как на ORACLE так и IB). Но конечно для построения комплексных запросов на сервере (при необходимости с хинтами и так далее) нужно руку набить. Хотя ничего невозможного нет.

stud (2004-04-21 16:25:00) [14]
жаль, что нам так и не удалось услышать начальника транспортного цеха)))

Sergey_Masloff (2004-04-21 16:21:00) [15]
>А кто такой TRefCursor?
TYPE TRefCursor IS REF CURSOR

можно еще так
TYPE TMyTableCursor IS REF CURSOR RETURN MYTABLE%ROWTYPE;

stud (2004-04-21 16:15:00) [16]
жаль, что нам так и не удалось услышать начальника транспортного цеха)))

Fay (2004-04-21 16:12:00) [17]
2Nikolay M. © (21.04.04 16:03) [27]
>> Кстати, это камень в огород "нет универсальной догмы" :)
Смотрел в огороде "нет универсальной догмы". Такого камня не видел.

Курдль (2004-04-21 16:09:00) [18]
А кто такой TRefCursor?

Nikolay M. (2004-04-21 16:03:00) [19]

> Ладно, сдаюсь! Нет универсальной догмы это лучше!

Yesss-yesss-yessss :))))

> Sergey_Masloff (21.04.04 15:39) [22]

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

Sergey_Masloff (2004-04-21 15:56:00) [20]
Ну а что ORACLE? В нем как раз очень просто за счет рефкурсоров
FUNCTION ReturnCustomCursor(pInput in number) return TRefCursor IS BEGIN OPEN cMyCursor FOR SELECT * FROM MyFavoriteTable WHERE FILTER = pInput ORDER BY MYSORTFIELD; return cMyCursor ; END;

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »