А 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 ...) и т.п, то тут уж без них я обойтись не могу.
Если очень интересует, могу выслать рабочие примеры...

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

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

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

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

Конечно, в большинстве случаев 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 для каждого возможного запроса :)

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

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. Я и сам больше люблю хранимые, мне просто за вьювы обидно стало :)
То ест

> Andryk © (27.05.03 18:08)

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

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

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

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

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

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

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

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

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