Как кто использует VIEW?
Как кто использует VIEW?
Наконец-то появился раздел гдеуместно задать сей вопрс, кои терзает меня уж давно как...
Читая книжки умныя не разу не встретил примера испльзования просмотра, из которого было б наглядно видно, что да в этом случае view облегчает жизнь или нечто подобное.
По тригерам, по процедурам, по UDF примеров много и довольно таки ярких.
Не пделитесь ли, как вы сами используете посмотры, и почему их используете. А то мне никак не прочувствовать сей бъект... он мне кажеться безполезным, а это порождает чувство непостигнутой истины и отдаления от просветленности
Читая книжки умныя не разу не встретил примера испльзования просмотра, из которого было б наглядно видно, что да в этом случае view облегчает жизнь или нечто подобное.
По тригерам, по процедурам, по UDF примеров много и довольно таки ярких.
Не пделитесь ли, как вы сами используете посмотры, и почему их используете. А то мне никак не прочувствовать сей бъект... он мне кажеться безполезным, а это порождает чувство непостигнутой истины и отдаления от просветленности
Абсолютно согласен.
У нас в базе среди 3000 тысяч объектов затерялись 2 (две) вьюхи. Кто-то из разработчиков в самом начале влепил, наверное, попробовать. Экспериментатор, блин
У нас в базе среди 3000 тысяч объектов затерялись 2 (две) вьюхи. Кто-то из разработчиков в самом начале влепил, наверное, попробовать. Экспериментатор, блин
А чего тут просветляться? Всё и так понятно - процедуры и триггеры решают практически любой круг задач, которые выполняют вьюхи, только гибче и управляемее.О! так это тоже сгодиться мне для просветления. хотелось бы ознакомиться со всеми сторонами впроса...
Склероз мне шепчет, что основной была идея секурности - чтоб пользователь/приложение о таблицах вообще не знал и тупо делал select * from pseudotable. Смешно. При полной открытости метаданных. А стоит дороговато в плане борзодействия и напряжения мозгов при их сджойнивании и т.п. Ну и всякие там хитрости типа агрегата из агрегатов. После появления derived tables в двойке я вообще не понимаю зачем они нужны.
у... понял. тольк если изначально считаешь, что "обновляемый" запрос не есть гуд совсем, то тоды ой...kdv писал(а):допустим, нужно сделать "обновляемым" сложный запрос.
хех... действительно весело... типа защита от дурака.Merlin писал(а):Склероз мне шепчет, что основной была идея секурности - .... Смешно. При полной открытости метаданных.
это мы такое не понимает.. это нам такое не известно. ага.Merlin писал(а):derived tables
у нас только IB6 под рукой и FB 1.5.3, честноскаченный, ибо бесплатный. на ем и будем строиться. а стремиться использовать самое свежее нам еще рано.. ибо и тут поле непахано.
Я подумал, что в принципе, для псевдоудобства можно было бы слепить въюху, где к шапке прицепленны все реквизиты документов из справочникв... что бы запрос на клиенте был легче, селект фром вью и все.
Но получается что на вьюху сервер будет не малосил на нее тратить...
так что уж лучше процедуру замутить, в нее и параметры можно давать... да....
Для простого селекта (а обычный джойн со справочниками - это простой запрос, сколько бы их там ни было, справочников-то) именно селект и лучше всего. Селективные процедуры хороши там, где одним запросом не справиться или он получается слишком тормозной из-за сложности для оптимизатора. И возвращаемый резалтсет должен быть небольшим, усечение длинного возврата Select From SP через Where неэффективно.
Я уже не помню что dimitr в последний раз говорил про современное состояние вопроса о проталкивании условий фильтрации и сджойнивания внутрь вья, в запрос. Но что-то точно не всегда получается. И нагрузка возрастает.kdv писал(а):view - это хранимый запрос. ему все равно, что запрос выполнять, что view.Но получается что на вьюху сервер будет не малосил на нее тратить...
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
У меня с вьюхами тож как-то не сложилось, нет ни одной.
Мы недавно столкнулись с проблемкой, вроде небольшой запрос, всего штук пяток джойнов не удалось скормить серверу из фокспро, из дельфей пожалйста, из ибэксперта пожалйста, а тут ни-ни. Моя в фоксе не силен, написал обертку, правда не вьюху, а ХП и понеслась.Я подумал, что в принципе, для псевдоудобства можно было бы слепить въюху, где к шапке прицепленны все реквизиты документов из справочникв... что бы запрос на клиенте был легче, селект фром вью и все.
например
1
когда надо сделать запрос к результату запроса...
Первичный запрос(как правило сложный с группировками и/или Union) при этом делается на View, а потом из него выбирается информация селектами как из датасета. Особенно полезно, когда используются динамически формируемые запросы в теле которых есть постоянная составляющая, которую собсно и выношу в View.
2
Например, список счетов, который не является отдельной таблицей в базе. Таким образом можно организовать связь "один ко многим" имея всего лишь одну таблицу, где "Мастер" организован в виде View
1
когда надо сделать запрос к результату запроса...
Первичный запрос(как правило сложный с группировками и/или Union) при этом делается на View, а потом из него выбирается информация селектами как из датасета. Особенно полезно, когда используются динамически формируемые запросы в теле которых есть постоянная составляющая, которую собсно и выношу в View.
2
Например, список счетов, который не является отдельной таблицей в базе. Таким образом можно организовать связь "один ко многим" имея всего лишь одну таблицу, где "Мастер" организован в виде View
Код: Выделить всё
CREATE VIEW "vw_accountsList"(
SCHETNUMBER,
FDATE,
NIK,
LK_SI,
CLIENT_ID,
SUMPRICE,
DISCONT,
RSLTPRICE,
SUMOPLATA,
SUMFCOUNT,
SUMPRODANO,
ERROR_FLAG)
AS
SELECT
SCHET.SCHETNUMBER,
SCHET.FDATE,
BOOK_CLIENTS.Nik,
SCHET.LK_SI,
SCHET.CLIENT_ID,
sum(SCHET.FCOUNT*SCHET.PRICE),
max(SCHET.Discont),
sum(SCHET.FCOUNT*SCHET.PRICE*(1.00-SCHET.Discont/100.00)),
sum(SCHET.OPLACHENO),
sum(SCHET.FCOUNT),
sum(SCHET.PRODANO),
max(SCHET.Error_Flag)
FROM SCHET
INNER JOIN BOOK_CLIENTS ON (BOOK_CLIENTS.Id_Client = SCHET.CLIENT_ID)
group by
SCHET.SCHETNUMBER,
SCHET.FDATE,
BOOK_CLIENTS.Nik,
SCHET.LK_SI,
SCHET.CLIENT_ID;
В запросе вязать ко вье ещё таблицу не лучший вариант. Оптимизатор видит кишки вьи и строить будет общий запрос, что может привести к неоптимальному соединению.DSKalugin писал(а):Таким образом можно организовать связь "один ко многим" имея всего лишь одну таблицу, где "Мастер" организован в виде View
В твоём случае, если нет необходимости редактировать эту вью непосредственно в гриде как обычную таблицу, процедура была бы эффективнее. И селект из неё делается точно так же.
и процедура - объект базы и вьюха - объект базы. Только вот объединять в одном запросе данные из ХП и таблиц крайне не рекомендуется. Поэтому если ставить вопрос xp vs view то я всегда выбираю последний вариант где это возможноWildSery писал(а): В твоём случае, если нет необходимости редактировать эту вью непосредственно в гриде как обычную таблицу, процедура была бы эффективнее. И селект из неё делается точно так же.
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Не поверите... ТУТА!!! "Что НЕ надо делать" http://www.ibase.ru/devinfo/dontdoit.htmIvan_Pisarevsky писал(а):Таки хотелось бы услышать что мне помешает с цифирьям полученным при помощи ХР прилефтджойнить данные справочников? А то я так делаю, а оно себе работает и ничего.Merlin писал(а): Кем? Хде?
п14 Не рекомендуется использовать связку "таблица+ХП"
, т.е. явный или неявный join таблицы с хранимой процедурой. В некоторых ситуациях наблюдалось неправильное выполнение запроса (Например, от пеpемены мест слагаемых, "сумма" иногда меняется.). Также ситуации сильно зависят от версий IB (4.x, 5.x, 6.x) - в одной из версий это может привести к падению сервера, в другой не выполнится, а в третьей - пройдет.
Во-первых, это рекомендации общие, а не строгие указания. Если умеешь пользоваться и понимаешь что получишь - кто тебе помешает? Я в некоторых случаях даже join двух процедур делаю.
Во-вторых, ты меня не понял. Процедурой я тебе рекомендовал заменить вью, но не джойнить к процедуре что-то ещё, а сделать на такой случай другую процедуру, которая уже точно знает, что как лучше сделать.
А всякие там супер-пупер динамически строящиеся запросы - либо не нужно, либо точно так же делается и без вьи.
Во-вторых, ты меня не понял. Процедурой я тебе рекомендовал заменить вью, но не джойнить к процедуре что-то ещё, а сделать на такой случай другую процедуру, которая уже точно знает, что как лучше сделать.
А всякие там супер-пупер динамически строящиеся запросы - либо не нужно, либо точно так же делается и без вьи.