Подскажите как сделать свой View?

[Александр]

для кеширования данных
если можно по шагам что и как?
исходные данные
1. есть запрос на выборку для view
2. обновление view нужно запускать при добавлении в базу какого либо объекта из разрешенных типов

ps
моя квалификация в SQL стремится к нулю

[Anderyt]

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

[Александр]

ну если не трудно для MS SQL по шагам не расскажешь? я просто не совсем понимаю почему обновлять не нужно?

[Anderyt]

итак, поехали.
открываем query analyzer (QA), подключаемся к нужной базе с нормальными правами (владельца)
если QA от сиквела 2000 и выше - то в дереве объектов слева (если нет - можно вызвать его через F8) надо раскрыть нужную базу и раскрыть папку Views.
берем ЛЮБОЙ вид, жмем на нем ПРАВОЙ кнопкой и говорим Script Object to new window as -> Create
такая команда открывает окошко со скриптом для создания объекта.
в этом скрипте нужно:
1. Поменять ИМЯ вида, оставив при этом старого владельца (в случае с Лоцией - lsdbo)
2. вставить нужный нам код выборки (то есть сиквел-запрос, возвращающий нужный результат) вместо имеющегося (это между as и первым GO)
в итоге должно получиться примерно так:

Код: Выделить всё

SET QUOTED_IDENTIFIER ON 
GO
SET ANSI_NULLS OFF 
GO

create view lsdbo.<название>
as
  <сиквел>
GO
SET QUOTED_IDENTIFIER OFF 
GO
SET ANSI_NULLS ON 
GO

рекомендую изменять в этом скрипте только имя и само тело запроса, все остальное оставить, как есть..
ну и в принципе все, запускаем этот скрипт - и вид сохраняется..
у меня обычно получается..
здесь только надо помнить, что и самодельные виды, и родные виды от лоции будут храниться вместе (если говорить про Лоцию), и никто не мешает Лоции при очередном обновлении сделать какой то хитрый вид, имя которого совпадет с самодельным видом... я так полагаю, что в этом случае самодельный вид перезапишется
поэтому лично я называю свои виды в виде
lsdbo.custom_view_<собственно>
надеюсь при этом на то, что Лоция не будет называть виды Custom_view

[Александр]

Огромное спасибо - всегда даешь исчерпывающие ответы

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

[Anderyt]

всегда пожалуйста
помогло хоть или нет?
насколько я понимаю, здесь все дело в самой сути.
вид - это определенный ЗАПРОС к таблицам.
соответсвенно, когда мы к нему обращаемся (тоже с помощью запроса), то на самом деле происходит просто обращение к реальным таблицам.
следовательно, информация в виде всегда актуальна момент обращения к этому виду..
я себе это так представляю

[Александр]

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

[Anderyt]

ну, не знаю про оптимизацию и планы выполнения, честно говоря
и что там можно ускорить и оптимизировать - еще вопрос
насколько я понял из умных книжек, смысл видов не в оптимизации и ускорении.
вид - это просто другой взгляд на таблицу. можно взять определенные колонки, а другие - не показывать.. например так..
а в случае с видами в Лоции все намного сложнее.
в родных видах собственно реализауется система защиты данных. не секрет, что таблицы видно только владельцу, простые пользователи их не видят. и собственно через интерфейс Лоции юзеры обращаются ТОЛЬКО к видам..
а вот в видах уже есть не только обращение к таблице с нужными данным (той же attrib_value), но и к таблицам с правами на эти данные.
в итоге в виде показываются только те данные, на которые у юзера есть права.
этим обычно и можно объяснить тот факт, почему запрос к таблице работает намного быстрее, чем запрос к соответствующему виду. вы сравните планы выполнения этих запросов, многое узнаете
но, конечно, нельзя вот так просто взять и дать права юзерам на таблицы. это то же самое, что и сделать все объекты общедоступными.
и сотрудники Лоции об этом постоянно напоминают, предостерегая от неправильных телодвижений
но!
при всем при этом, лично у меня получилось найти такие массивы информации в таблицах, которые не требуют серьезной защиты и к которые нужно посмотреть очень быстро.
поэтому я просто сделал нужные виды, в которых обращался только к нужным таблицам, не обращая внимания на права.. но надо понимать, что посредством этих видов информация становится доступной всем абсолютно.
поэтому за это отвечает только администратор.
ааааа!!!!
самое главное,
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Александр!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
я забыл сразу сказать. после того, как вид создан, нужно дать на него права на select для группы party_users. иначе вид будет доступен только владельцу

[Александр]

а на счет прав я не совсем понимаю необходимость защиты Лоции?
(быть может просто еще не столкнулись )

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

и в общем не совсем понятно - нужна ли защита объектов на уровне хп Лоции
где она может проявиться? ведь защиты от администратора нет (в смысле если есть пароль на базу Лоции и SQL) и соответственно всю защиту (разграничение прав пользователей) можно смело убрать в макросы - не трогая быстродействия базы?
ну мне так кажется
ps
поголовная защита - может быть и хороша - но это же потеря скорости
pps
а скажи, для расширения кругозора - сколько своих видов вы используете в базе? ориентировочно? Просто сейчас я планирую один вид - но быть может стоит задуматься над этим плотнее - и сделать пару десятков нужных видов?????

[Anderyt]

соответственно в виде мы покажем только свободные атрибуты

это КАКИМ образом? фильтровать как то? по типу атрибута?
дак вот в видах лоции это уже и используется, так же есть обращение к таблице, которая определяет видимость на уровне типов атрибутов (я в этом почти уверен )
можно конечно городить свое - но это уже дело такое....
вся ответственность будет лежать мы сами знаем на ком
у нас используется порядка 10 видов.
в них конечно нигде нет ссылок на таблицы с правами (как в родных видах), но и данные там такие, которые никто не сможет никому продать допустим, сделали вид для истории документов без учета права на документы. вытащили это в отчет Лоции, назвав Последние документы. показывает, какие документы и когда открывал юзер (почти полный аналог виндового списка Пуск - Документы, но больше информации. тип доступа, дата и время и так далее). даже если там окажется инфа о каком то секретном документе - сам документ все равно не открыть.. ну а из информации, кто и что открывал мы пока тайну делать не собираемся
еще есть вид, который опять же без учета прав на объекты делает хитрое слияние таблиц party и flow, показывает, какие объекты находятся в каких картах. то есть какой объект, у кого, как долго и в рамках какой работы. очень интересная штука получилась..
еще одна фишка... нужно было вытащить некоторую финансовую инфу и сделать это очень быстро (инфы много очень). но ясно, что это уж точно далеко не общедоступное. в итоге сделали вид, но дали на него права не группе party_users, а специальной группе сервера. в итоге конечно получили некоторое усложнение администрирования (пользователей фин. отдела нужно вести не только в Лоции, но и на уровне сервера БД), но зато получили ОГРОМНЫЙ выигрыш по скорости работы отчета.

[Disillusioned]

Помимо обычных view, существуют и так называемые материализованные (есть в Sybase SQL Anywhere 10, насчет MS SQL и Oracle не знаю), которые по сути представляют из себя таблицы, в которые периодически или по событию записываются результаты выполнения запроса. Для редко изменяемых данных могут быть очень полезными.
Что касается вопроса SQL-запросов и прав, то помимо представлений, может помочь использование ХП. Пишем ХП, в которой обращаемся к любым таблицам и видам, которые нам нужны, потом выдаем права на выполнение ХП пользователю или группе. Конечно, здесь тоже надо быть осторожным, но, на мой взгляд, риск здесь меньше, чем при создании собственного view.
Обычно в собственных видах и ХП я обращаюсь в запросах к object_reference_view, а прочие данные получаю уже из таблиц напрямую (tree_link, attrib_value и т.д.). С одной стороны потеря производительности минимальная, а с другой стороны права польностью не игнорируются.

[Anderyt]

кстати да, очень логично.
получается, что мы смотрим ТОЛЬКО на права на сам экземпляр объекта

[Александр]

попробовал свой View - получилось не очень интересно - выполняется также как и запрос (по времени) (в нем просто 5 поздапросов - объект+ атрибуты)
можно конечно упростить запрос и объекты выбирать в виде а атрибуты по id из вида или еще как
но....
конкретно в моем случае не очень..., проще получается отвлечь внимание юзера от задержек всякими заморочками в диалоге....

в MS SQL есть не материализованные а индексированные виды - тоже самое вид сбоку, но только в Enterprise редакции для MSSQL2000 и во всех 2005, а у нас как назло Standard 2000

так что видно придеться пока еще на своих массивах посидеть

[Anderyt]

стоп стоп... дак а в чем был смысл использования вида?
если сделать в виде тот же запрос, котороый уже есть и который работает по тем же видам, то вряд ли вид будет быстрее выдавать информацию, чем запрос.
я так понимаю, если мы задаемся целью уменьшить время на получение данных, то надо сделать сначала так, чтобы запрос выполнялся быстрее, а уже потом - запихивать его в вид..
например, можно делать запрос, не учитывающий права (ну, или учитывающий НЕ ВСЕ права), так ДОЛЖНО стать быстрее..

[Александр]

хотелось получить ускоренную выборку данных, кеширование редко изменяющихся но часто используемых - т.е. именно то что о чем говорил Disillusioned

но стоп. может я действительно чего то не понял
на счет прав...
в запросе я использую обращение к видам Лоции - т.е. автоматически гдето-в этих видах идет проверка прав?

т.е. смысл был обратиться не к видам а к реальным данным
или как?