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

← →
Dimedrol (2003-05-26 13:00) [0]

До сих пор никогда не пользовалcя Views
и прекрасно себя чувствовал.
Но может я чего-то теряю в жизни ? ;-)

Не подскажет ли кто, какой-нибудь примерчик,
где с использованием Views проблема
решается очень изящно, в отличие от
других способов решения.

И вообще, как Views могут существенно
помочь в программировании баз данных.

Еще есть такой воспрос:
вот например у меня таблица 80000 записей
с текстами и т.п.
Если например я создам View которое выбирает
40000 записей по каким-либо критериям, напр. ID>40000
или еще что-то, то SELECT из этого View будет
быстрее чем из основной таблицы или как ?

Ну вы меня понимаете,
хотелось бы немного практических советов... ;-)

← →
Johnmen (2003-05-26 13:06) [1]

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

Круче только яйца ! (вареные)...

Лично я применяю редко. Только когда нужен выход из ситуации "запрос-на-запрос".

← →
Alexandr (2003-05-26 13:06) [2]

забей.
это для тех недосерверов, в которых SP нету.
А остальные придерживаются стандарту.

Ну есть еще правда Обновляемые View но это для тех, кто ищет гемор на свою...

← →
Alexandr (2003-05-26 13:13) [3]

да, и еще разграничение прав в зависимости от значения в поле таблицы.
Ну и запрос на запрос - но для этого SP есть.

← →
Dimedrol (2003-05-26 13:55) [4]

Типа в производительности не выиграю ?
по-любому ?...

← →
Reindeer Moss Eater (2003-05-26 13:56) [5]

Иногда немного выиграешь.

← →
Dimedrol (2003-05-26 15:38) [6]

Типа в производительности не выиграю ?
по-любому ?...

← →
Dimedrol (2003-05-26 15:39) [7]

2 Reindeer Moss Eater

А что это могут быть за случаи такие экзотические ?

← →
Reindeer Moss Eater (2003-05-26 15:39) [8]

Иногда немного выиграешь.

← →
Dimedrol (2003-05-26 15:40) [9]

Когда ?

← →
Reindeer Moss Eater (2003-05-26 15:43) [10]

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

← →
Stas (2003-05-26 15:51) [11]

Представление это нормально
Не вижу недостатков

← →
Danilka (2003-05-26 15:53) [12]

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

У нас в базе (правда, Орокол, а не IB) - около 500 табиц, и 700 вьюх, основная работа (%95) идет с вьюхами, напрямую с таблицами - очень мало.

← →
Stas (2003-05-26 16:00) [13]

Да у меня MSSQL SERVER тоже достаточно представлений, может на IB они глючные ?

← →
Zacho (2003-05-26 16:39) [14]

> Stas © (26.05.03 16:00)

Не знаю, не видел глюков с VIEW на IB, а возможность создавать триггера на VIEW - очень даже полезная.

← →
Stas (2003-05-26 16:42) [15]

Приходим к выводу что VIEW это не только полезная вещь, но и нужная.

← →
Dimedrol (2003-05-27 10:20) [16]

2 Zacho
А какие "полезные" триггеры можно юзать вместе с VIEW ?

← →
Жук (2003-05-27 10:28) [17]

> Stas © (26.05.03 16:42)
> Приходим к выводу что VIEW это не только полезная вещь,
> но и нужная.

Полезная, но не всегда нужная :-)

← →
Andryk (2003-05-27 11:10) [18]

Views - это довольно мошный инструмент, для большей читабельности кода. В приципе ведь можно писать и на ассемблере, но все же лучше использовать языки высокого уровня. Так и со Views если дать ему осмысленное название, то запрос будет уже легче читать. Ну а по производительности, тоже можно выиграть, например при создании View в запросе поставить нужные хинты.
Так что мое мнение, если вы не используете Views, то вы дествительно многое теряте.

← →
Zacho (2003-05-27 11:45) [19]

> Dimedrol © (27.05.03 10:20)

Before Insert/Update/Delete естественно :-)
C помощью триггеров на VIEW можно любое VIEW сделать обновляемым (т.е. делать для него Insert, Delete, Update так же, как и с обычной таблицей). Как уже отмечали, крайне удобно использовать такие VIEW для разграничения прав доступа по отдельным записям, при этом в триггерах можно проверять, есть ли пользователя право на данное действие.

← →
Dimedrol (2003-05-27 12:26) [20]

Ну допустим...

Ну а все-таки, если сделать VIEW которое делит таблицу
на 2 части например по ID > XXX
и по каким-либо другим критериям, скажем БЕЗ
какого-либо JOIN-на

То ОТТУДА - из этого VIEW, SELECT будет быстрее
или все таки нет ?

← →
Zacho (2003-05-27 12:42) [21]

> Dimedrol © (27.05.03 12:26)

Попробуй - узнаешь :-)
А вообще, imho, сколько-нибудь ощутимая разница в скорости будет только если запрос, которым формируется VIEW достаточно сложный и требующий значительного времени для выполнения (не для фетча !)

← →
Карелин Артем (2003-05-27 14:29) [22]

А я все на SP делаю. Это круче представлений. А для обновления данных есть в дельфине компоненты.

← →
Andryk (2003-05-27 14:48) [23]

2Dimedrol

> Ну а все-таки, если сделать VIEW которое делит таблицу
> на 2 части например по ID > XXX
> и по каким-либо другим критериям, скажем БЕЗ
> какого-либо JOIN-на
>
> То ОТТУДА - из этого VIEW, SELECT будет быстрее
> или все таки нет ?

Ну вообще-то почему это должно быть быстрее?! Views это просто тотже самый SQL-запрос, и как быстро будет он выполнятся это зависит только от организации таблиц, индексов и т.п.
Я еще раз повторюсь, что вьюхи созданы для облечения чтения запросов.
Ну например, предположим есть у вас таблица клиентов и истории клиента
Client(
ID,
Code)
Client_his(
CLIENT_ID,
BANK_CODE,
ACCOUNT,
DATE_FROM,
DATE_TO)
Так вот например вам нужно иметь в нескольких запросах актуальную на сегодня информацию о клиенте. Можно конечно каждый раз писать простенький запрос типа
select *
from CLIENT c,
CLIENT_HIS ch,
.........
where c.ID = ch.CLIENT_ID
and sysdate between ch.DATE_FROM and ch.DATE_TO
..........

но можно просто создать вьюху

create or replace view V_CLIENT as
select *
from CLIENT c,
CLIENT_HIS ch
where c.ID = ch.CLIENT_ID
and sysdate between ch.DATE_FROM and ch.DATE_TO

и уже во всех запросах использовать ее

select *
from V_CLIENT,
.......

Будет ли это быстрее? Нет не будет, но будет более удобно для вас же.
ЗЫ. Приведенный код Oracle, так как на IB не работаю, но думаю что и там та же идеология.

← →
Andryk (2003-05-27 14:50) [24]

> Карелин Артем © (27.05.03 14:29)
> А я все на SP делаю. Это круче представлений. А для обновления
> данных есть в дельфине компоненты.

А что вы все делаете на SP?

← →
Карелин Артем (2003-05-27 15:00) [25]

>А что вы все делаете на SP
Так точно.

← →
Andryk (2003-05-27 15:20) [26]

2Карелин Артем ©
Нет меня интересует, что именно вы делаете, и чем круче это VIEW? По моему это разные вещи. Хотя, может я не правльно понял SP - это Stored Procedure?
И не надо делать вид, что вы не поняли вопроса.

← →
Zacho (2003-05-27 15:55) [27]

> Карелин Артем © (27.05.03 14:29)
> А я все на SP делаю. Это круче представлений. А для обновления
> данных есть в дельфине компоненты.

Вообще-то есть разница между реализацией логики обновления данных на клиенте и на сервере (с помощью триггеров на VIEW).
Конечно, можно все делать через SP, но через VIEW во многих случаях проще.

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

Andryk © (27.05.03 15:20)
Ну когда надо делать сложные выборки из 2-6 завязанных таблиц и показывать в одном гриде, да если еще операции зависят от значений параметров (if ... then ...) и т.п, то тут уж без них я обойтись не могу.
Если очень интересует, могу выслать рабочие примеры...

← →
Andryk (2003-05-27 16:35) [29]

> Карелин Артем © (27.05.03 16:16)
> Andryk © (27.05.03 15:20)
> Ну когда надо делать сложные выборки из 2-6 завязанных таблиц
> и показывать в одном гриде, да если еще операции зависят
> от значений параметров (if ... then ...) и т.п, то тут уж
> без них я обойтись не могу.
> Если очень интересует, могу выслать рабочие примеры...

Ну так опять же непонятно, если вы используете SP, в запросе в секции where, то я не вижу причин не использовать их же во вьюхах.
Но если же вы используете функции возвращающие курсор, то это другой вопрос. Дело в том что данный подход хоть и работает, но использовать его практически везде, это не правильно, так как реляционные базы как раз создавались для того, чтобы довольно простым языком запросов (каким является SQL) можно было вытащить кучу данных.
Ну а рабочие примеры, мне ни к чему, я верю что они работают. Но просто меня удивило ваше заявление А я все на SP делаю. Это круче представлений.

← →
Карелин Артем (2003-05-27 17:06) [30]

Andryk © (27.05.03 16:35)
А еще мне часто бывают нужны процедуры на вставку, возвращающие значение идентификатора записи; процедуры, в которых от значений входных параметров меняется условие выборки...
ИМХО, SP более мощный и гибкий инструмент.

← →
Карелин Артем (2003-05-27 17:09) [31]

Да ну их в баню... Пора пиво пить :)

← →
Sandman25 (2003-05-27 17:29) [32]

Конечно, в большинстве случаев SP - более мощный и гибкий инструмент. Но вот представим себе, что у нас есть некая контрольная точка на доступ к некоторой таблице. Если у пользователя установлена эта контрольная точка, то он "видит" все записи из таблицы, иначе не видит. CREATE VIEW view1 as SELECT * FROM table1 WHERE EXISTS (SELECT ...), где вложенный SELECT представляет собой проверку доступа) будет эффективнее, нагляднее и удобнее, чем вызов хранимой процедуры, возвращяющей кучу записей. Особенно, если мы хотим написать что-либо типа SELECT column1 FROM view1 WHERE column2=3 AND column3=1 OR column9 BETWEEN 15 and 19; Не создавать же SP для каждого возможного запроса :)

← →
Sandman25 (2003-05-27 17:31) [33]

"ВозвращЯющей"... Да, не думал я, что когда-нибудь так напишу :)

← →
Andryk (2003-05-27 18:08) [34]

2 Sandman25 ©
Не ну всегда можно внутри этой процедуры сделать select :о)))

← →
Sandman25 (2003-05-27 18:23) [35]

Andryk
Но иногда это будет медленнее. Поясню еще раз - бывают ситуации, когда заранее неизвестно, какие фильтры установит пользователь. Например, в Informix-4GL есть специальная возможность, когда пользователю показывается форма со всеми полями таблицы и он сам устанавливает, как он хочет фильтровать записи. В итоге на выходе из этой формы мы имеем строку, в которой записано, например "column1=23 AND column2 < 15", которую сформировал сам пользователь. При использовании view я просто строю динамический запрос, добавляя эту строку к строке "select * from view1 where", а что мне делать при использовании хранимых? Самому анализировать строку и вызывать процедуру с 15 параметрами (по одному на каждое поле), из которых только 2 не пустые? А ведь пользователь может поставить и фильтр column1=1 or column1 between 15 and 20 or column1 between 25 and 36 or column1 > 48...Что в таком случае делать? Открытые массивы в хранимую передавать? :)

PS. Я и сам больше люблю хранимые, мне просто за вьювы обидно стало :)
То ест

← →
Zacho (2003-05-27 18:26) [36]

> Andryk © (27.05.03 18:08)

Можно. Но на мой взгляд, удобнее одно VIEW с триггерами, с которым можно работать как с обычной таблицей, чем 4 SP (для SELECT, INSERT, DELETE, UPDATE).

← →
Andryk (2003-05-27 18:31) [37]

2 Sandman25
Гм... то ли я так не удачно пошутил :о(, то ли вы не обратили внимание на самалик в конце моего поста, то ли вы не внимательно читали мои предыдущие посты, в которых я по-моему как раз и пытался доказать, что вьюхи, вещь хоть и не необходимая, но все же очень полезная.
Так что меня в этом убежать не надо.

2 Карелин Артем
И все же я так и не понял, почему вы не используете вьюхи?

← →
Sandman25 (2003-05-27 18:33) [38]

Andryk
Извините... Исправлюсь :)

← →
Карелин Артем (2003-05-28 09:19) [39]

Andryk © (27.05.03 18:31)
>И все же я так и не понял, почему вы не используете вьюхи?
Потому что не умею :-) И не вижу в этом нужды.
Sandman25 © (27.05.03 18:23)
>При использовании view я просто строю динамический запрос, добавляя эту строку к строке "select * from view1 where", а что мне делать при использовании хранимых?
А что мешает делать запрос select * from StoredProc1 where??

← →
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 (2003-05-29 10:38) [63]

← →
Карелин Артем (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]

← →
Жук (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) - это круто ? Найти похожие ветки