ХП или запрос?
ХП или запрос?
несколько абстракный вопрос
Какими критериями следует руководствоваться, если есть выбор:
строить "многоэтажный" запрос или реализовать аналогичную логику в ХП?
Ести ли вообще некие общие критерии, либо все зависит от конкретных условий задачи?
[Модератор: тема перемещена из раздела "Общие проблемы"]
Какими критериями следует руководствоваться, если есть выбор:
строить "многоэтажный" запрос или реализовать аналогичную логику в ХП?
Ести ли вообще некие общие критерии, либо все зависит от конкретных условий задачи?
[Модератор: тема перемещена из раздела "Общие проблемы"]
Re: ХП или запрос?
Как правило скорость и возможности, т.е. есть некоторые задачи которые запросом сделать очень очень трудно.stix-s писал(а):несколько абстракный вопрос
Какими критериями следует руководствоваться, если есть выбор:
строить "многоэтажный" запрос или реализовать аналогичную логику в ХП?
Некоторые вещи даже "многоэтажным" запросом нереализуемы в принципе. Это один критерий.
Второй критерий - размещение бизнес-логики.
Я (в данный момент) приверженец идеи, что клиент должен знать только названия процедур, которые ему отдадут данные, и процедур, которые заберут от него результат его работы (в том числе на вставку/удаление/редактирование), а вся логика и бизнес-логика - на сервере в ХП.
Второй критерий - размещение бизнес-логики.
Я (в данный момент) приверженец идеи, что клиент должен знать только названия процедур, которые ему отдадут данные, и процедур, которые заберут от него результат его работы (в том числе на вставку/удаление/редактирование), а вся логика и бизнес-логика - на сервере в ХП.
Re: ХП или запрос?
по по воду возможностей - это очевидно - то, что трудоемко или невозможно в запросе делается в ХП, а вот как например по скорости определяться - строить запрос и ХП и опытным путем скорости выполнения сравнивать?eugeney писал(а):Как правило скорость и возможности, т.е. есть некоторые задачи которые запросом сделать очень очень трудно.
хочется определиться, при какой "этажности " запроса стоит на него плюнуть и ваять ХП
мммм, попытка избежать копания исходного кода на клиенте при изменении бизнес-логики?WildSery писал(а): ..... а вся логика и бизнес-логика - на сервере в ХП.
Re: ХП или запрос?
Сравнивать что? Один и тот же запрос в фас и профиль? Очень смешно.stix-s писал(а):а вот как например по скорости определяться - строить запрос и ХП и опытным путем скорости выполнения сравнивать?
Да. Не просто "копании кода", даже самой необходимости пересборки клиент-проекта. А также при изменении структуры и места хранения данных.stix-s писал(а):мммм, попытка избежать копания исходного кода на клиенте при изменении бизнес-логики?
Ась? Это что нельзя выполнять через запросы что можно через SP? Пример запроса на проэкцию данных плиз.WildSery писал(а):Некоторые вещи даже "многоэтажным" запросом нереализуемы в принципе. Это один критерий.
Примеры модификации в n-таблицах не подходит.
Эх. Прошлый век. Насчет n-tier приложений не думали? Что бизнес логику выгоднее описывать OOP понятиями а не в виде relations.WildSery писал(а):Второй критерий - размещение бизнес-логики.
Я (в данный момент) приверженец идеи, что клиент должен знать только названия процедур, которые ему отдадут данные, и процедур, которые заберут от него результат его работы (в том числе на вставку/удаление/редактирование), а вся логика и бизнес-логика - на сервере в ХП.
C селективными ХП всё хорошо и замечательно ровно до тех пор покаWildSery писал(а): Я (в данный момент) приверженец идеи, что клиент должен знать только названия процедур, которые ему отдадут данные, и процедур, которые заберут от него результат его работы (в том числе на вставку/удаление/редактирование), а вся логика и бизнес-логика - на сервере в ХП.
а) Их не надо друг с другом джойнить. В общем-то вопрос решается написанием ещё одной ХП, но как-то монстроидально получается и в проекте средней сложности, когда их количество перевалит за пару тыщ, затрахаешься размножать модификации по табуну таких ХП, внутри которых есть запрос, который надо модифицировать.
б) На них не надо накладывать условия фильтрации и сортировки. Будет вседа строиться полный резалтсет и эти операции будут выполняться над ним. А он может быть мама не горюй.
Я конечно могу жахнуть сюда экранов 6-7 кода процедуры, и экранов 30 метаданных зацепленных ею таблиц, но оно тебе вправду надо? Более того, может оно и можно на самом деле записать в виде одного многоэтажного хитрого джойна, увешанного подзапросами с кейзами как новогодняя ёлка, но мне лениво даже про него думать, потому что запросто может сорвать крышу. А оптимизатору её точно сорвёт на его выполнении.eugeney писал(а):Ась? Это что нельзя выполнять через запросы что можно через SP? Пример запроса на проэкцию данных плиз.WildSery писал(а):Некоторые вещи даже "многоэтажным" запросом нереализуемы в принципе. Это один критерий.
Например, вывести все "дырки" в первичном ключе, но не диапазонами, а перечислением.eugeney писал(а):Ась? Это что нельзя выполнять через запросы что можно через SP? Пример запроса на проэкцию данных плиз.
Думал. Не дорос ещё.eugeney писал(а):Насчет n-tier приложений не думали? Что бизнес логику выгоднее описывать OOP понятиями а не в виде relations.
Про relations не понял. При чём тут?
Почему-то таких случаев перекладывания одного и того же на разный лад не попадалось. Особенности проекта?Merlin писал(а):затрахаешься размножать модификации по табуну таких ХП, внутри которых есть запрос, который надо модифицировать
Сортировка и так строится по полному резалтсету, нет? Хотя, согласен, это тяжёлый случай, узкое место тут - объём передаваемых по сети данных.Merlin писал(а):На них не надо накладывать условия фильтрации и сортировки.
Фильтрация - не согласен. Мне никогда не нужна была "фильтрация как юзер захочет", обычно только по нескольким полям (дата, тип чего-нибудь, измерение, etc.), рулится входными параметрами ХП.
Re: ХП или запрос?
Угу, очень смешно, когда в ХП при определенных условиях результат получается за 10мс, а в запросе за 1 мин - я не говорю, что запросы одинаковые, одинаков получаемый результат.WildSery писал(а): Сравнивать что? Один и тот же запрос в фас и профиль? Очень смешно.
Тоже к этому склоняюсь, но это далеко не универсальное решение, все одно при изменении количества входных/выходных параметров придется клиентов перелопачиватьWildSery писал(а): Да. Не просто "копании кода", даже самой необходимости пересборки клиент-проекта. А также при изменении структуры и места хранения данных.
ЫЫЫЫЫЫЫЫ, а почему за меня? я не просилMerlin писал(а): То есть? Я должен напрячься и за тебя придумать простой пример?
меня мнения по критериям ХП-запрос интересуют, может, конечно здесь конкретные примеры и пригодятся, кстати.
Понимаешь, надеюсь этот вопрос не только мне интересен, мож еще кому пригодится.
Читай мой пост.stix-s писал(а):может попроще что есть ?
Если запросы разные - зачем их сравнивать? В процедуре ты меняешь запрос с конкретной целью - ускорить его работу (иначе нафига?), какой тут тогда может быть выбор?stix-s писал(а):Угу, очень смешно, когда в ХП при определенных условиях результат получается за 10мс, а в запросе за 1 мин - я не говорю, что запросы одинаковые, одинаков получаемый результат.
Когда прочитал в книжках про View и SP, загорелся идеей:
а) Переместить бизнес-логику в базу;
б) С помощью них "скрыть" структуру базы.
Но, подумав, одумался. Дело в том, что почти во всех случаях база данных (имеется ввиду файл) и клиентская часть - неразрывное целое. И прятать детали реализации (ну и защищать в том числе) от самого себя - пустая трата ресурсов. Поэтому стараюсь при возможности использовать запрос из таблиц. В случае, если это неприменимо - ХП. Это по пункту б. По пункту а: бизнес-логику все-таки в большинстве случаев проще кодировать в клиентской части.
Резюмирую:
В настоящий момент ХП использую в следующих случаях:
1. Для генерации отчетов;
2. Для случаев, когда возвращается одна строка (например, адрес лицевого счета);
3. Для сложной обработки информации.
Имхо, надо стремиться к уменьшению количества ХП, но до разумного предела.
а) Переместить бизнес-логику в базу;
б) С помощью них "скрыть" структуру базы.
Но, подумав, одумался. Дело в том, что почти во всех случаях база данных (имеется ввиду файл) и клиентская часть - неразрывное целое. И прятать детали реализации (ну и защищать в том числе) от самого себя - пустая трата ресурсов. Поэтому стараюсь при возможности использовать запрос из таблиц. В случае, если это неприменимо - ХП. Это по пункту б. По пункту а: бизнес-логику все-таки в большинстве случаев проще кодировать в клиентской части.
Резюмирую:
В настоящий момент ХП использую в следующих случаях:
1. Для генерации отчетов;
2. Для случаев, когда возвращается одна строка (например, адрес лицевого счета);
3. Для сложной обработки информации.
Имхо, надо стремиться к уменьшению количества ХП, но до разумного предела.
Читал, но в твоем примере выбор однозначен - только ХП, я же имею в виду случаи, когда можно реализовать и так и сяк.WildSery писал(а):Читай мой пост.
ммм, возможно я не совсем внятно объяснил, что меня интересуетkdv писал(а): топик мутный. какие-то "критерии", то пример хочу, то не хочу...
возьмем, например:
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
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
но всегда ли оправдано построение индекса для ускорения запроса? ведь тут еще зависит, сколько дубликатов
возможно в других случаях правильнее использовать ХП?
сорри за столь здоровенный пост
ты в курсе, как выполняется твой замечательный запрос? А про хранимые агрегаты? Я уже давно не видел запросов, которые несчастные 100к записей перемалывают 2 часа. Так что ты не в том направлении смотришь - не надо насиловать оперативные или архивные данные.PLAN SORT ((T2 NATURAL))
PLAN (T1 NATURAL)
[quote="stix-s"][/quote]Ерундой занимаешься, вот и получаются часы-минуты.
У тебя должна быть TB2 со списком этих самых клиентов. Соответственно не надо выбирать уникальные UID из общей помойки.
И ещё, сама постановка задачи хромает, или я её не понял. У тебя выведутся больше нуля строк только если max(v1) и max(v2) будут в одной строке, иначе ой.
[CyberMax: Что за ненормативная лексика? Выбирай выражения, не в казарме находишься]
Прошу прощения
У тебя должна быть TB2 со списком этих самых клиентов. Соответственно не надо выбирать уникальные UID из общей помойки.
И ещё, сама постановка задачи хромает, или я её не понял. У тебя выведутся больше нуля строк только если max(v1) и max(v2) будут в одной строке, иначе ой.
[CyberMax: Что за ненормативная лексика? Выбирай выражения, не в казарме находишься]
Прошу прощения
Последний раз редактировалось WildSery 06 окт 2006, 16:49, всего редактировалось 1 раз.
kdv писал(а): PLAN SORT ((T2 NATURAL))
PLAN (T1 NATURAL)
ты в курсе, как выполняется твой замечательный запрос?
аааааааааа, господа-товарищи, да дело не в запросе том и не в структуре БДWildSery писал(а): Долб@@бством занимаешься, вот и получаются часы-минуты.
мне лишь важно узреть побольше мнений, когда следует ХП использовать, а когда запрос
в приведенном примере я лишь хочу показать, что достаточно элементарный запрос выполняется даже при наличии индекса медленнее, чем ХП!
не надо дискуссии, просто выскажите свое мнение, когда вы ХП пользуете, а когда запрос