ХП или запрос?

[stix-s]

несколько абстракный вопрос
Какими критериями следует руководствоваться, если есть выбор:
строить "многоэтажный" запрос или реализовать аналогичную логику в ХП?
Ести ли вообще некие общие критерии, либо все зависит от конкретных условий задачи?

[Модератор: тема перемещена из раздела "Общие проблемы"]

[eugeney]

несколько абстракный вопрос
Какими критериями следует руководствоваться, если есть выбор:
строить "многоэтажный" запрос или реализовать аналогичную логику в ХП?

Как правило скорость и возможности, т.е. есть некоторые задачи которые запросом сделать очень очень трудно.

[WildSery]

Некоторые вещи даже "многоэтажным" запросом нереализуемы в принципе. Это один критерий.
Второй критерий - размещение бизнес-логики.
Я (в данный момент) приверженец идеи, что клиент должен знать только названия процедур, которые ему отдадут данные, и процедур, которые заберут от него результат его работы (в том числе на вставку/удаление/редактирование), а вся логика и бизнес-логика - на сервере в ХП.

[stix-s]

Как правило скорость и возможности, т.е. есть некоторые задачи которые запросом сделать очень очень трудно.

по по воду возможностей - это очевидно - то, что трудоемко или невозможно в запросе делается в ХП, а вот как например по скорости определяться - строить запрос и ХП и опытным путем скорости выполнения сравнивать?
хочется определиться, при какой "этажности " запроса стоит на него плюнуть и ваять ХП

..... а вся логика и бизнес-логика - на сервере в ХП.

мммм, попытка избежать копания исходного кода на клиенте при изменении бизнес-логики?

[WildSery]

а вот как например по скорости определяться - строить запрос и ХП и опытным путем скорости выполнения сравнивать?

Сравнивать что? Один и тот же запрос в фас и профиль? Очень смешно.

мммм, попытка избежать копания исходного кода на клиенте при изменении бизнес-логики?

Да. Не просто "копании кода", даже самой необходимости пересборки клиент-проекта. А также при изменении структуры и места хранения данных.

[eugeney]

Некоторые вещи даже "многоэтажным" запросом нереализуемы в принципе. Это один критерий.

Ась? Это что нельзя выполнять через запросы что можно через SP? Пример запроса на проэкцию данных плиз.
Примеры модификации в n-таблицах не подходит.

Второй критерий - размещение бизнес-логики.
Я (в данный момент) приверженец идеи, что клиент должен знать только названия процедур, которые ему отдадут данные, и процедур, которые заберут от него результат его работы (в том числе на вставку/удаление/редактирование), а вся логика и бизнес-логика - на сервере в ХП.

Эх. Прошлый век. Насчет n-tier приложений не думали? Что бизнес логику выгоднее описывать OOP понятиями а не в виде relations.

[Merlin]

Я (в данный момент) приверженец идеи, что клиент должен знать только названия процедур, которые ему отдадут данные, и процедур, которые заберут от него результат его работы (в том числе на вставку/удаление/редактирование), а вся логика и бизнес-логика - на сервере в ХП.

C селективными ХП всё хорошо и замечательно ровно до тех пор пока

а) Их не надо друг с другом джойнить. В общем-то вопрос решается написанием ещё одной ХП, но как-то монстроидально получается и в проекте средней сложности, когда их количество перевалит за пару тыщ, затрахаешься размножать модификации по табуну таких ХП, внутри которых есть запрос, который надо модифицировать.

б) На них не надо накладывать условия фильтрации и сортировки. Будет вседа строиться полный резалтсет и эти операции будут выполняться над ним. А он может быть мама не горюй.

[Merlin]

Некоторые вещи даже "многоэтажным" запросом нереализуемы в принципе. Это один критерий.

Ась? Это что нельзя выполнять через запросы что можно через SP? Пример запроса на проэкцию данных плиз.

Я конечно могу жахнуть сюда экранов 6-7 кода процедуры, и экранов 30 метаданных зацепленных ею таблиц, но оно тебе вправду надо? Более того, может оно и можно на самом деле записать в виде одного многоэтажного хитрого джойна, увешанного подзапросами с кейзами как новогодняя ёлка, но мне лениво даже про него думать, потому что запросто может сорвать крышу. А оптимизатору её точно сорвёт на его выполнении.

[WildSery]

Ась? Это что нельзя выполнять через запросы что можно через SP? Пример запроса на проэкцию данных плиз.

Например, вывести все "дырки" в первичном ключе, но не диапазонами, а перечислением.

Насчет n-tier приложений не думали? Что бизнес логику выгоднее описывать OOP понятиями а не в виде relations.

Думал. Не дорос ещё.
Про relations не понял. При чём тут?

затрахаешься размножать модификации по табуну таких ХП, внутри которых есть запрос, который надо модифицировать

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

На них не надо накладывать условия фильтрации и сортировки.

Сортировка и так строится по полному резалтсету, нет? Хотя, согласен, это тяжёлый случай, узкое место тут - объём передаваемых по сети данных.
Фильтрация - не согласен. Мне никогда не нужна была "фильтрация как юзер захочет", обычно только по нескольким полям (дата, тип чего-нибудь, измерение, etc.), рулится входными параметрами ХП.

[stix-s]

Сравнивать что? Один и тот же запрос в фас и профиль? Очень смешно.

Угу, очень смешно, когда в ХП при определенных условиях результат получается за 10мс, а в запросе за 1 мин - я не говорю, что запросы одинаковые, одинаков получаемый результат.

Да. Не просто "копании кода", даже самой необходимости пересборки клиент-проекта. А также при изменении структуры и места хранения данных.

Тоже к этому склоняюсь, но это далеко не универсальное решение, все одно при изменении количества входных/выходных параметров придется клиентов перелопачивать

[stix-s]

Я конечно могу жахнуть сюда экранов 6-7 кода процедуры, и экранов 30 метаданных зацепленных ею таблиц, .

Максимализм, однако может попроще что есть ?

[Merlin]

Я конечно могу жахнуть сюда экранов 6-7 кода процедуры, и экранов 30 метаданных зацепленных ею таблиц, .

Максимализм, однако может попроще что есть ?

То есть? Я должен напрячься и за тебя придумать простой пример?

[stix-s]

То есть? Я должен напрячься и за тебя придумать простой пример?

ЫЫЫЫЫЫЫЫ, а почему за меня? я не просил
меня мнения по критериям ХП-запрос интересуют, может, конечно здесь конкретные примеры и пригодятся, кстати.
Понимаешь, надеюсь этот вопрос не только мне интересен, мож еще кому пригодится.

[WildSery]

может попроще что есть ?

Читай мой пост.

Угу, очень смешно, когда в ХП при определенных условиях результат получается за 10мс, а в запросе за 1 мин - я не говорю, что запросы одинаковые, одинаков получаемый результат.

Если запросы разные - зачем их сравнивать? В процедуре ты меняешь запрос с конкретной целью - ускорить его работу (иначе нафига?), какой тут тогда может быть выбор?

[kdv]

топик мутный. какие-то "критерии", то пример хочу, то не хочу...

[CyberMax]

Когда прочитал в книжках про View и SP, загорелся идеей:
а) Переместить бизнес-логику в базу;
б) С помощью них "скрыть" структуру базы.
Но, подумав, одумался. Дело в том, что почти во всех случаях база данных (имеется ввиду файл) и клиентская часть - неразрывное целое. И прятать детали реализации (ну и защищать в том числе) от самого себя - пустая трата ресурсов. Поэтому стараюсь при возможности использовать запрос из таблиц. В случае, если это неприменимо - ХП. Это по пункту б. По пункту а: бизнес-логику все-таки в большинстве случаев проще кодировать в клиентской части.

Резюмирую:
В настоящий момент ХП использую в следующих случаях:
1. Для генерации отчетов;
2. Для случаев, когда возвращается одна строка (например, адрес лицевого счета);
3. Для сложной обработки информации.
Имхо, надо стремиться к уменьшению количества ХП, но до разумного предела.

[stix-s]

Читай мой пост.

Читал, но в твоем примере выбор однозначен - только ХП, я же имею в виду случаи, когда можно реализовать и так и сяк.

топик мутный. какие-то "критерии", то пример хочу, то не хочу...

ммм, возможно я не совсем внятно объяснил, что меня интересует
возьмем, например:
http://forum.ibase.ru/phpBB2/viewtopic.php?t=2453
таблицу увеличил до 100000 записей
сделал у себя копию таблицы, таблицу увеличил до 100000 записей
индекс только по полю RID-первичный ключ
с ХП

Код: Выделить всё

CREATE PROCEDURE PR_TB1 
RETURNS (
    PRID INTEGER,
    PUID INTEGER,
    PF1 VARCHAR(10),
    PF2 VARCHAR(10),
    PV1 INTEGER,
    PV2 INTEGER)
AS
DECLARE VARIABLE VUID INTEGER;
DECLARE VARIABLE VV1 INTEGER;
DECLARE VARIABLE VV2 INTEGER;
begin
  /* Procedure Text */
  for select t1.uid, max(t1.v1), max(t1.v2) from tb1 t1
   group by t1.uid  into :vuid,:vv1,:vv2
     do
     begin
      select t2.rid, t2.uid,t2.f1,t2.f2,t2.v1,t2.v2 from tb1 t2
       where t2.uid=:vuid and t2.v1=:vv1 and t2.v2=:vv2
       into :prid,:puid,:pf1,:pf2,:pv1,:pv2;
        suspend;
     end
end

------ Performance info ------
Prepare time = 32ms
Execute time = 12s 312ms
Avg fetch time = 439,71 ms
Current memory = 1 010 796
Max memory = 1 098 780
Memory buffers = 2 048
Reads from disk to cache = 1
Writes from cache to disk = 3
Fetches from cache = 315 180 077

с запросом

Код: Выделить всё

select t1.rid, t1.uid, t1.f1,t1.f2,t1.v1,t1.v2 
from tb1 t1 
where (select t2.uid 
 from tb1 t2 
 where t1.uid=t2.uid 
 group by uid 
 having t1.v1=max(t2.v1) and t1.v2=max(t2.v2) 
 ) is not null

План
PLAN SORT ((T2 NATURAL))
PLAN (T1 NATURAL)

Адаптированный план
PLAN SORT ((T2 NATURAL)) PLAN (T1 NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 2h 22m 36s 828ms
Avg fetch time = 427 841,40 ms
Current memory = 851 748
Max memory = 986 644
Memory buffers = 2 048
Reads from disk to cache = 958
Writes from cache to disk = 6
Fetches from cache = -711 804 446

построение индекса по UID меняет ситуацию кардинально
с ХП
------ Performance info ------
Prepare time = 125ms
Execute time = 31ms
Avg fetch time = 1,19 ms
Current memory = 1 009 676
Max memory = 1 089 852
Memory buffers = 2 048
Reads from disk to cache = 1
Writes from cache to disk = 3
Fetches from cache = 43 828

с запросом
План
PLAN (T2 ORDER TB1_IDX1)
PLAN (T1 NATURAL)

Адаптированный план
PLAN (T2 ORDER TB1_IDX1) PLAN (T1 NATURAL)

------ Performance info ------
Prepare time = 0ms
Execute time = 3s 484ms
Avg fetch time = 174,20 ms
Current memory = 1 071 284
Max memory = 1 206 180
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 6
Fetches from cache = 1 633 272

но всегда ли оправдано построение индекса для ускорения запроса? ведь тут еще зависит, сколько дубликатов
возможно в других случаях правильнее использовать ХП?

сорри за столь здоровенный пост

[kdv]

PLAN SORT ((T2 NATURAL))
PLAN (T1 NATURAL)

ты в курсе, как выполняется твой замечательный запрос? А про хранимые агрегаты? Я уже давно не видел запросов, которые несчастные 100к записей перемалывают 2 часа. Так что ты не в том направлении смотришь - не надо насиловать оперативные или архивные данные.

[WildSery]

[quote="stix-s"][/quote]Ерундой занимаешься, вот и получаются часы-минуты.
У тебя должна быть TB2 со списком этих самых клиентов. Соответственно не надо выбирать уникальные UID из общей помойки.

И ещё, сама постановка задачи хромает, или я её не понял. У тебя выведутся больше нуля строк только если max(v1) и max(v2) будут в одной строке, иначе ой.

[CyberMax: Что за ненормативная лексика? Выбирай выражения, не в казарме находишься]
Прошу прощения

[stix-s]

PLAN SORT ((T2 NATURAL))
PLAN (T1 NATURAL)
ты в курсе, как выполняется твой замечательный запрос?

Долб@@бством занимаешься, вот и получаются часы-минуты.

аааааааааа, господа-товарищи, да дело не в запросе том и не в структуре БД
мне лишь важно узреть побольше мнений, когда следует ХП использовать, а когда запрос
в приведенном примере я лишь хочу показать, что достаточно элементарный запрос выполняется даже при наличии индекса медленнее, чем ХП!
не надо дискуссии, просто выскажите свое мнение, когда вы ХП пользуете, а когда запрос