1С++ users forum - Использование VIEW для ограничения доступа к данным.

(UTC)

1С++ users forum › 1С++ и прочие расширения v7 › Курилка › Использование VIEW для ограничения доступа к данным.

(Группа Модераторов: 1c++ moderator)

‹ Предыдущая Тема | Следующая Тема ›

Страницы: 1 [2]

Отправить

Печать

Использование VIEW для ограничения доступа к данным. (число прочтений - 7763 )

AndreyM Full Member Отсутствует Сообщений: 166 Местоположение: Харьков Зарегистрирован: 13. Февраля 2008 Пол:	Re: Использование VIEW для ограничения доступа к данным. Ответ #15 - 25. Июля 2011 :: 19:07	Печать
	chessman писал(а) 25. Июля 2011 :: 10:41: Если не использовать VIEW WITH SCHEMABINDING, то конструкция подобная Спр.НайтиПоКоду() будет выдавать ошибку с дальнейшим вылетом базы или нужно патчить bkEnd, убирать хинты 'INDEX' Да, сорри, не обратил внимание на изменение основных таблиц в начале поста. Действительно без SCHEMABINDING будут вылетать ошибки при указании индекса, т.к. эта инструкция связывает таблицу с представлением. Только тоже не понятно - почему именно так пытаешься реализовать? Что будет видеть менеджер, например, в документе, которому запрещаешь видеть определенного клиента - <Объект не найден ...>? chessman писал(а) 25. Июля 2011 :: 10:50: Имеется ввиду индекс у самой VIEW? да

	Правильно поставленный вопрос, уже содержит половину ответа.
	ICQ IP записан

chessman God Member Отсутствует Сообщений: 1084 Зарегистрирован: 10. Августа 2007	Re: Использование VIEW для ограничения доступа к данным. Ответ #16 - 26. Июля 2011 :: 05:10	Печать
	AndreyM писал(а) 25. Июля 2011 :: 19:07: Только тоже не понятно - почему именно так пытаешься реализовать? Что будет видеть менеджер, например, в документе, которому запрещаешь видеть определенного клиента - <Объект не найден ...>? Так я же не только для справочника сделал view, но и для шапки и табличной части документа. AndreyM писал(а) 25. Июля 2011 :: 19:07: chessman писал(а) 25. Июля 2011 :: 10:50: Имеется ввиду индекс у самой VIEW? да Долго экспериментировал и решил отказаться от этой затеи, т.к. нужно выполнить кучу условий, на типы полей, на функции, чтобы создать индекс у вью.


	IP записан

chessman God Member Отсутствует Сообщений: 1084 Зарегистрирован: 10. Августа 2007	Re: Использование VIEW для ограничения доступа к данным. Ответ #17 - 26. Июля 2011 :: 07:00	Печать
	UNION ALL и INNER JOIN пришлось заменить на LEFT JOIN и WHERE, т.к. иначе слетает уникальность столбцов ROW_ID и тогда не проходит верификация. Скроллинг в стандартных работает незаметно.


	IP записан

AndreyM Full Member Отсутствует Сообщений: 166 Местоположение: Харьков Зарегистрирован: 13. Февраля 2008 Пол:	Re: Использование VIEW для ограничения доступа к данным. Ответ #18 - 26. Июля 2011 :: 10:43	Печать
	chessman писал(а) 26. Июля 2011 :: 05:10: AndreyM писал(а) 25. Июля 2011 :: 19:07: Только тоже не понятно - почему именно так пытаешься реализовать? Что будет видеть менеджер, например, в документе, которому запрещаешь видеть определенного клиента - <Объект не найден ...>? Так я же не только для справочника сделал view, но и для шапки и табличной части документа. Для шапки - это пол-беды, по графе отбора можно отобрать, а если запрещен товар, например, то как поступать? Если вьюшка на товар ограничивает видимость для определенного менеджера, то будет <Объект не найден>, а если в журнале исключить данный документ, то 1) отбор документов для журнала будет крайне тормознутый; 2) нелогично не показать менеджеру документ, в котором есть хоть один товар, который он "не ведёт". chessman писал(а) 26. Июля 2011 :: 05:10: AndreyM писал(а) 25. Июля 2011 :: 19:07: chessman писал(а) 25. Июля 2011 :: 10:50: Имеется ввиду индекс у самой VIEW? да Долго экспериментировал и решил отказаться от этой затеи, т.к. нужно выполнить кучу условий, на типы полей, на функции, чтобы создать индекс у вью. Условий там немного, вьюшки получаются простые, но в результате очень функциональные и прироста скорости работы - очень много. Только в базе 1С нельзя реализовать - они сбрасывают оператор ARITHABORT

	Правильно поставленный вопрос, уже содержит половину ответа.
	ICQ IP записан

chessman God Member Отсутствует Сообщений: 1084 Зарегистрирован: 10. Августа 2007	Re: Использование VIEW для ограничения доступа к данным. Ответ #19 - 26. Июля 2011 :: 11:10	Печать
	Похоже рано я радовался...SQL хоть и отбрасывает Индексы, но из-за этого сообщения: Код Внимание! Подсказки индекса для представления "SC133" будут пропущены. (строк обработано: 1) курсор неправильно устанавливается....блин, как бы это информационное сообщение отключить?


	IP записан

chessman God Member Отсутствует Сообщений: 1084 Зарегистрирован: 10. Августа 2007	Re: Использование VIEW для ограничения доступа к данным. Ответ #20 - 26. Июля 2011 :: 11:21	Печать
	AndreyM писал(а) 26. Июля 2011 :: 10:43: а если запрещен товар, например, то как поступать? Если вьюшка на товар ограничивает видимость для определенного менеджера, то будет <Объект не найден>, а если в журнале исключить данный документ, то 1) отбор документов для журнала будет крайне тормознутый; 2) нелогично не показать менеджеру документ, в котором есть хоть один товар, который он "не ведёт". Это уже другая задача, понятно, что универсально все не сделаешь. AndreyM писал(а) 26. Июля 2011 :: 10:43: Условий там немного, вьюшки получаются простые, но в результате очень функциональные и прироста скорости работы - очень много. Только в базе 1С нельзя реализовать - они сбрасывают оператор ARITHABORT Ну как немного, в 1С есть поля типа 'text', и на такие таблицы уже не натянешь индексы; функции, используемые во вью должны быть детерминированными, а например, SUSER_SNAME() таковой не является, а как без нее можно идентифицировать пользователя? От 'text' можно отказаться, а от функций, у меня не получилось.


	IP записан

AndreyM Full Member Отсутствует Сообщений: 166 Местоположение: Харьков Зарегистрирован: 13. Февраля 2008 Пол:	Re: Использование VIEW для ограничения доступа к данным. Ответ #21 - 26. Июля 2011 :: 12:10	Печать
	chessman писал(а) 26. Июля 2011 :: 11:21: Это уже другая задача, понятно, что универсально все не сделаешь. Э брат... Зачем же огород городить, если потом всё переделывать? Сделать фундамент, вывести стены, а потом фундамент менять? Стены не рухнут? chessman писал(а) 26. Июля 2011 :: 11:21: Ну как немного, в 1С есть поля типа 'text', и на такие таблицы уже не натянешь индексы Так и в таблице не натянешь индекс на поле текст - вьюшки непричем chessman писал(а) 26. Июля 2011 :: 11:21: функции, используемые во вью должны быть детерминированными, а например, SUSER_SNAME() таковой не является, а как без нее можно идентифицировать пользователя? Это логично: индексированная вьюшка должна быть в результате "таблицей", со строгими данными, а не подбором по текщему условию. С SUSER_SNAME() нужно поиграться... Возможно, создать вьюшку (SC133_global) со всеми пользователями (занести их в таблицу) и с их разрешенными товарами, например. Потеряешь только на индексе (в плане объема базы данных). A подмененная вьюшка SC133 будет с отбором из SC133_global по SUSER_SNAME() и без индексов, но это не страшно - будут использоваться индексы SC133_global. Может еще что-то придумаешь... Дерзай! но направление, по-моему, тупиковое...

	Правильно поставленный вопрос, уже содержит половину ответа.
	ICQ IP записан

Страницы: 1 [2]

Отправить

Печать

‹ Предыдущая Тема | Следующая Тема ›

« Главная ‹ Раздел Вверх