А чего тут просветляться? Всё и так понятно - процедуры и триггеры решают практически любой круг задач, которые выполняют вьюхи, только гибче и управляемее.О! так это тоже сгодиться мне для просветления. хотелось бы ознакомиться со всеми сторонами впроса...
у... понял. тольк если изначально считаешь, что "обновляемый" запрос не есть гуд совсем, то тоды ой...kdv писал(а):допустим, нужно сделать "обновляемым" сложный запрос.
хех... действительно весело... типа защита от дурака.Merlin писал(а):Склероз мне шепчет, что основной была идея секурности - .... Смешно. При полной открытости метаданных.
это мы такое не понимает.. это нам такое не известно. ага.Merlin писал(а):derived tables
Я уже не помню что dimitr в последний раз говорил про современное состояние вопроса о проталкивании условий фильтрации и сджойнивания внутрь вья, в запрос. Но что-то точно не всегда получается. И нагрузка возрастает.kdv писал(а):view - это хранимый запрос. ему все равно, что запрос выполнять, что 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 писал(а): В твоём случае, если нет необходимости редактировать эту вью непосредственно в гриде как обычную таблицу, процедура была бы эффективнее. И селект из неё делается точно так же.
Не поверите... ТУТА!!!Ivan_Pisarevsky писал(а):Таки хотелось бы услышать что мне помешает с цифирьям полученным при помощи ХР прилефтджойнить данные справочников? А то я так делаю, а оно себе работает и ничего.Merlin писал(а): Кем? Хде?
"Что НЕ надо делать" http://www.ibase.ru/devinfo/dontdoit.htm п14 Не рекомендуется использовать связку "таблица+ХП"
, т.е. явный или неявный join таблицы с хранимой процедурой. В некоторых ситуациях наблюдалось неправильное выполнение запроса (Например, от пеpемены мест слагаемых, "сумма" иногда меняется.). Также ситуации сильно зависят от версий IB (4.x, 5.x, 6.x) - в одной из версий это может привести к падению сервера, в другой не выполнится, а в третьей - пройдет.