А Views (в IB) - это круто ?

← →
Andrey (2003-05-28 10:23) [40]

Позволю себе указать господам на еще один способ применения "вьюх" в сочетании с SP: http://www.volny.cz/iprenosil/interbase/ip_ib_isc4.htm

Наверняка многие это читали но в пылу спора позабыли :)

P.S. Сам я "вьюхи" не использую... почти не использую... нужды такой пока не возникало.

← →
passm (2003-05-28 10:29) [41]

А я вообще только через VIEW работу клиента организовываю. Правда использую DB2.
Дает логическое разделение: это данные а это объекты для работы с ними. Больше возможностей для определения прав доступа. И гибче.

← →
Sandman25 (2003-05-28 10:53) [42]

Карелин Артем © (28.05.03 09:19)
>А что мешает делать запрос select * from StoredProc1 where??

А то, что Informix не поддерживает такой синтаксис :)
А для тех СУБД, что поддерживают, происходит огромная потеря эффективности - сначала вызывается StoredProc1, которая возвращает ВСЕ записи И поля из таблицы, и только потом происходит фильтрование/выборка. Может мне только одно поле из одной записи надо, а тут хранимая зачем-то всю таблицу приносит. Похоже на файл-серверную технологию, кстати :)

← →
Sandman25 (2003-05-28 11:04) [43]

>>И все же я так и не понял, почему вы не используете вьюхи?
>Потому что не умею :-) И не вижу в этом нужды.

Одно с другим тесно связано. Я тоже не вижу нужды в технологиях, которые не умею использовать. А если бы я попробовал, может и понравилось. Глядишь, и нужду бы заметил :)

← →
Andryk (2003-05-28 11:51) [44]

> Карелин Артем © (28.05.03 09:19)
> Потому что не умею :-) И не вижу в этом нужды.

Нда уж. И почему же вы тогда заявляете, что использование SP это круче чем использование View?

Когда-то давно когда я только начинал программировать на Turbo Pascal, я уже думал что я довольно крутой программер :о), мне мой знакомый, как-то говорит:
- а ты почему в своих программах не используешь динамическую памать?
- дык я не умею, и не вижу в этом необходимости.
- Так ты не используешь 80% мощности языка.

Так вот не использование вьюх, по-моему личному мнению, это потеря эффективности 50%. Как например у вас будет работать оптимизатор при попытке соеденить в запросе например результат процедуры и таблицы? Или вам все равно каким образом сервер будет выбирать записи?

И опять же мое мнение: запрос из процедуры это конечно довольно мощный и гибкий инструмент, но он далеко не самый эффектиный путь.

← →
Romkin (2003-05-28 12:24) [45]

У меня ни в одной базе нет View :-))
select SP - на Interbase это иногда на порядок быстрее, чем view, да и читабельнее.
А насчет фильтрации view - так на нее индекс все равно не посадишь, так что и разницы нет, откуда
select * from smb
догадайтесь, из чего, из процедуры или таблицы или view?
а в процедуру всегда входные параметры можно сделать, для выборки, вот и получается, что select SP и быстрее, и универсальнее. Кстати, пример:
http://romkin.pochtamt.ru/script.htm
процедуры, начинающиеся с list_... это и есть view

← →
Romkin (2003-05-28 12:28) [46]

2Andryk запрос из процедуры на IB - самый быстрый и эффективный путь :-)
А вот соединять в запросе таблицу и ХП - очень дурной тон, начал с процедуры - продолжай. Мне, например, такого соединения никогда не надо было.

← →
Andryk (2003-05-28 12:53) [47]

2 Romkin
Ну не знаю как в IB, но в Oracle сам View - это ни что иное, как тот же SQL запрос, и оптимизатор использует те же индексы, какие бы использовал если вместо View в запрос добавить объединение таблиц.

← →
Sandman25 (2003-05-28 16:21) [48]

>Ну не знаю как в IB, но в Oracle сам View - это ни что иное, как тот же SQL запрос, и оптимизатор использует те же индексы, какие бы использовал если вместо View в запрос добавить объединение таблиц.

В Informix то же самое. Причем в случае ошибочной автоматической стратегии выполнения select"а можно указать директивы оптимизации как для всего select, так и отдельно для view (в create view).

← →
Romkin (2003-05-28 18:31) [49]

IB, естественно, то же самое. Вот только когда пишешь lookup, гораздо быстрее сделать for select на основную таблицу, и в теле цикла выбрать поля из справочников, никакого объединения таблиц, все запросы простые

← →
Zacho (2003-05-28 20:59) [50]

> Romkin © (28.05.03 18:31)

Может я чего-то не понял или ошибаюсь, но, imho
FOR SELECT ... FROM TABLE_1 INTO .. DO
BEGIN
SELECT .. FROM TABLE_2 WHERE .. INTO ..
SUSPEND;
END
должно работать медленнее (причем гораздо), чем SELECT ... FROM TABLE_1 JOIN TABLE_2 ON ..
Только что провел небольшой эксперимент - запрос отрабатывает быстрее более чем в 10 раз, чем ХП.
P.S. А причем здесь VIEW ?

← →
Zacho (2003-05-28 21:21) [51]

> Zacho © (28.05.03 20:59)

Немного добавлю - я экспериментировал с довольно небольшими таблицами, основная примерно 1000 записей, справочник около 12000 записей. Execute time для SELECT * FROM STORED_PROC было более 300 ms, для SELECT ... JOIN ... - 20 ms при первом запуске. При повторных выполнениях результаты почти сравнялись, видимо потому, что страницы с данными закешировались.

← →
kaif (2003-05-29 01:55) [52]

Один момент я попытался в IB перейти на VIEW, но столкнулся с одной проблемой. В документации сказано, что если назначены триггеры вставки, удаления и обновления, то VIEW безусловно передает управление этим триггерам. Да, это так в случае выборки более, чем из 1 таблицы (для read-only наборов). Но в случае с 1 таблицей VIEW почему-то по доброте душевной сам делает вставку, невзирая на наличие триггера. В результате я долго не мог понять, что происходит (нарушение уникального ключа), пока не отключил триггер. Это несоотвествие поведения документации и еще кое-какое неоговоренное в документации поведение (особенные требования к вычисляемым полям) несколько меня смутили и я отказался от использования VIEW. Но что касается скорости - я не заметил ни тормоза, ни ускорения по сравнению с SP. И пока что обхожусь без VIEW.
Видимо, идеальное применение VIEW это когда обязательно нужно произвести изменения в структуре базы (разделить одну таблицу на две или три таблицы), а приложения переписывать не хочется или невозможно - тогда VIEW могут имитировать то, что раньше было одной таблицей, а теперь хранится уже в нескольких таблицах. Кстати именно такое применение VIEW рекомендовано в документации самими разработчиками.

← →
Жук (2003-05-29 08:31) [53]

> Romkin © (28.05.03 12:28)
> А вот соединять в запросе таблицу и ХП - очень дурной тон,
> начал с процедуры - продолжай. Мне, например, такого соединения
> никогда не надо было.

Дурной тон ? Почему ? Помнится, при обучении программированию на ТР, нам говорили, что ставить ";" перед end"ом - дурной тон.
Ваше заявление о несовместимости :
1) Идеологическое;
2) Из разряда : "мне не надо => моветон";
3) Или есть какие-то объективные причины ?

Контрпример : Необходимо отсортировать адреса по номеру дома, а т.к. нумерация домов допускает значения "34а", "221-бис", "13/666", то хранение в IB осуществляется в varchar, следовательно сортировка будет по алфавиту, а не по возрастанию.
Вполне логично в этом случае обратится в ХП для перевода № из varchar в integer, и отсортировать уже по результату из ХП, получаем запрос, где данные для отображения берём из таблиц, а служебное поле для сортировки из результатов ХП.

← →
Danilka (2003-05-29 09:04) [54]

Жук © (29.05.03 08:31)
дурной тон потому-что соединение будет native, индексы не будут использоваться.

Честно говоря, мне очень не нравятся гиперзапросы на десять листов, намного читабельнее небольшие запросы. А как этого достичь - делать логические предзапросы. Есть несколько таблиц, есть вьюхи на эти таблицы которые делают предварительный отбор, какие-то соединения по этим таблицам.
Основной запрос, который работает с этими вьюхами будет намного меньше и удобнее для понимания, чем тот-же самый запрос но по самим таблицам.

Это то-же самое, что можно на паскале все сделать в теле одной процедуры, а можно разбить на логические функции, которые, кстати, будут использоваться и в других процедурах.
Первый путь - источник глюков, трудночитаемого кода, куча переменных обьявленых в главной процедуре и т.д., с этим все согласятся? Почему мне то-же самое не делать на SQL?
Зачем мне огромные процедуры, без использования функций?
Зачем мне десять запросов, часть кода которых повторяется, не правильнее ли вынести эту часть кода во вьюху?

← →
Zacho (2003-05-29 09:19) [55]

> Жук © (29.05.03 08:31)

Нсчет join"ов c ХП: в IB (насколько мне известно, во всех версиях и клонах) есть баги, проявляющиеся при таких запросах, и приводящие к выдаче неверного результата и даже падению сервера. Так что пользоваться этом можно, если осторожно :-)
Я, например, предпочитаю обходиться без таких запросов именно по этой причине. При необходимости - лучше напишу еще одну ХП.

← →
Жук (2003-05-29 09:26) [56]

> Danilka © (29.05.03 09:04)
> Жук © (29.05.03 08:31)
> ...индексы не
> будут использоваться

Неправда

> Zacho © (29.05.03 09:19)

Ого ! А откуда такая инфа ?

← →
Карелин Артем (2003-05-29 09:30) [57]

Провел эксперимент: взял список всех улиц РФ(~500 000) и сделал хранимую процедуру типа:
For select distinct(имя улицы) from ... select count(*) from ... where имя <улицы>=:<имя улицы>
и через 12 секунд получил отсортированный по числу одинаковых названий список улиц. Чаще всего встречается улица "молодежная".
Это быстро или медленно?

Zacho © (28.05.03 21:21)
Если проиндексировать системные таблицы, то можно будет получить более высокую скорость в первый запуск.

P.S. Раз идет переход во флейм, может начнем генераторами меряться?

← →
Zacho (2003-05-29 09:34) [58]

Да не помню точно уже. Сам не натыкался, скорее всего потому, что почти не использую join"ы с ХП. Но упоминания об этом встречал неоднократно - скорее всего на www.ibase.ru и news://forums.demo.ru/epsylon.public.interbase Да помнится не так давно и здесь (точнее,в "Базах") было подобное.

← →
Zacho (2003-05-29 09:58) [59]

> Жук © (29.05.03 09:26)
>
> > Danilka © (29.05.03 09:04)
> > Жук © (29.05.03 08:31)
> > ...индексы не
> > будут использоваться
>
> Неправда

Для join"а таблицы с ХП - не будут, ибо откуда взяться индексам у резалтсета, возвращаемого ХП ?

> Карелин Артем © (29.05.03 09:30)

А ты сделай то же самое запросом, а не ХП и сравни результаты.
И время фетча - не показатель, более интересно время выполнения запроса и кол-во чтений с диска и из кэша.
> Если проиндексировать системные таблицы, то можно будет
> получить более высокую скорость в первый запуск.

А причем здесь системные таблицы ? Насколько я понимаю, в случае с ХП для выборки каждой записи из "основной" таблицы происходит select из "справочной".Посмотри план - он должен быть типа INDEX (..). А в случае запроса с join - будет произведено соединение по индексам, и план будет join(index,..)
Может, я и ошибаюсь - пусть тогда объяснит кто-нибудь более знающий.

← →
Жук (2003-05-29 10:06) [60]

> Zacho © (29.05.03 09:58)
> Для join"а таблицы с ХП - не будут...

Речь идёт о запросе типа :
select t.*,p.rez from mtable t,mproc(t.mfield) p order by p.rez

← →
Zacho (2003-05-29 10:11) [61]

> Жук © (29.05.03 10:06)

Ну вот именно для соединения mtable и mproc индексы использоваться не будут. Посмотри план такого запроса.

← →
Жук (2003-05-29 10:22) [62]

> Zacho © (29.05.03 10:11)
Посмотри план такого запроса.

Не могу - нет плана. :-(

← →
Zacho (2003-05-29 10:38) [63]

> Жук © (29.05.03 10:22)

А куда же он делся ? :-)

← →
Карелин Артем (2003-05-29 10:38) [64]

Zacho © (29.05.03 09:58)
Когда делаешь выборку из хранимых процедур, то около 100 мс идет на выборку их системных таблиц. Читай тут http://ibase.ru/devinfo/gspeed.htm

← →
Danilka (2003-05-29 10:39) [65]

Zacho © (29.05.03 10:38)
видимо, все выкурили :))

← →
Жук (2003-05-29 10:41) [66]

> А куда же он делся ? :-)

:-) Хрен знает. Нет и всё. Может броузер глючит, может ещё что...
Вам не трудно привести пример плана на подобный запрос ?

← →
Жук (2003-05-29 10:44) [67]

> Danilka © (29.05.03 10:39)
> видимо, все выкурили :))

Да уж. Сам сижу - смеюсь, читая. Наверное план подействовал. :-)
Сорри за флейм.

← →
Карелин Артем (2003-05-29 10:46) [68]

← →
Zacho (2003-05-29 11:00) [69]

> Жук © (29.05.03 10:41)

План будет примерно такой: PLAN JOIN (mproc NATURAL,t NATURAL)
Но именно такой запрос, имхо вообще не выполнится.

> Карелин Артем © (29.05.03 10:38)

Понятно. Но даже с учетом этих 100ms разница все равно получается приличная.

← →
Жук (2003-05-29 11:14) [70]

> Zacho © (29.05.03 11:00)
> План будет примерно такой: PLAN JOIN (mproc NATURAL,t NATURAL)

А вот и нет :
Запрос :
select k.id_inrec,a.a_fam
from awtor_knigi(158) a,kniga k
План :
PLAN JOIN (AWTOR_KNIGA INDEX (IDX_AWTOR_KNIGA1),JOIN (A INDEX (PK_AWTOR),S INDEX (RDB$PK_STRANYK NATURAL)

>Но именно такой запрос, имхо вообще не выполнится.
Ваше имхо абсолютно верно :-)

← →
Andryk (2003-05-29 11:24) [71]

> Карелин Артем © (29.05.03 09:30)
> P.S. Раз идет переход во флейм, может начнем генераторами
> меряться?

Да уж дествительно пора :о))
Но есть еще один аргумент на использование View, ну чторошо, вот сейчас вы пишите на IB, а завтра заказчик потребует на Oracle или на чем-нибудь другом. И что вам придется все переписывать. А синтаксис запроса из ХП очень сильно различается, а вот из View практически нет.

← →
Карелин Артем (2003-05-29 11:28) [72]

Ну вот, я себя начал плохо чувствовать, потому как View не пользуюсь.

← →
Andrey (2003-05-29 14:01) [73]

По поводу связки таблица+SP
http://ibase.ru/devinfo/dontdoit.htm
пункт 14.

← →
Жук (2003-05-29 14:04) [74]

Интересует как раз IB6, т.е. та версия, где эта связка работает нормально.

← →
Zacho (2003-05-29 14:14) [75]

> Жук © (29.05.03 14:04)

Да нигде она нормально не работает. По крайней мере, недавно здесь кто-то писал, что у него падал серевер при подобной связке. И, насколько помню - Yaffil. А в Ya исправлена куча багов по сравнению с IB 6

← →
Andryk (2003-05-29 16:14) [76]

> Zacho © (29.05.03 14:14)
> Да нигде она нормально не работает. По крайней мере, недавно
> здесь кто-то писал, что у него падал серевер при подобной
> связке. И, насколько помню - Yaffil. А в Ya исправлена куча
> багов по сравнению с IB 6

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

← →
kaif (2003-05-29 18:37) [77]

Связка таблицы и ХП работает прекрасно. Я это использую в тысячах случаев и никогда не сталкиваюсь с проблемами. Правда я стараюсь избегать LEFT OUTER JOIN. Но скажу Вам, что с LEFT OUTER JOIN могут быть проблемы и при объединениях просто таблиц.
У меня всего однажды была проблема при использовании UNION внутри ХП с объединением результатов ХП и таблицы.
А проблем вообще избежать невозможно.
Вот сегодня простейший запрос с агрегатными функциями по одной таблице с группировкой и упорядочиванием по 4 неагрегатным полям в плане никак не хотел использовать специально сделанный для этой цели индекс по этим 4 полям. Пришлось план вписывать в запрос руками. Сервер Yaffils 821.

Так что от проблем никто никогда не гарантирован.

Я утверждаю, что пункт 14 правил

http://ibase.ru/devinfo/dontdoit.htm

неверен.
С таким же успехом я могу заявить (и уже как-то даже в сердцах такое делал): "Никогда не используйте UNION", "Никогда не используйте UPDATABLE VIEW", никогда не используйте рекурсивные процедцры, никогда не используйте индексы, так как они могут в принципе испортиться и т.д. и т.п.

Но тогда кроме голого SELECT * FROM TABLE1 ничего не останется.

← →
Sandman25 (2003-05-29 19:13) [78]

>Но тогда кроме голого SELECT * FROM TABLE1 ничего не останется.

НИКОГДА не используйте SELECT * FROM TABLE1 :)
Потому что когда в таблицу добавят еще поля, Вам придется переделывать запрос.
Я теперь даже при вставке пишу INSERT INTO TABLE1(COL1, COL2,COL3) VALUES(1,2,3) потому как зачастую получается, что приходится добавлять в таблицу еще поля (с DEFAULT-значением или разрешающие NULL).

← →
Zacho (2003-05-29 19:42) [79]

> Andryk © (29.05.03 16:14)

Не думаю, что это аргумент. У ХП возможностей гораздо больше, чем у VIEW, и заменить ХП на VIEW просто не получится. Да и вообще, imho, спор VIEW vs SP - довольно бессмысленный. Что именно использовать - зависит только от конкретной задачи. Например, в моем текущем проекте нет ни одного VIEW. А в одном из предидущих было много и VIEW и SP.

> kaif © (29.05.03 18:37)

Практически со всем согласен.
Но ! Если бы все было прекрасно, то этот 14 пункт просто бы не появился. Я не собираюсь говорить "никогда не используйте JOIN с SP" но и заявлять, что никаких проблем нет, тоже бы поостерегся. Самое печальное, что неизвестно, при каких условиях вылазит этот баг.

> Но скажу Вам, что с LEFT OUTER JOIN могут быть проблемы
> и при объединениях просто таблиц.

Какие ? Весьма любопытно, вроде бы еще не сталкивался.

А Views (в IB) - это круто ? Найти похожие ветки