Тормоза с правами "Подразделение и дочерние" CRM 4.0

[Tony Green]

Коллеги!

А не сталкивался ли кто-нибудь с такой проблемой:

Если в роли пользователя установлен уровень доступа к чтению кастомной сущности "Подразделение и дочерние подразделения", то при открытии представлений и при быстром поиске у пользователя ощущаются сильнейшие торомоза.



Если же уменьшить уровень доступ до просто "Подразделение", тормоза бесследно исчезают.

Вот такая вот загадка

[a33ik]

А под админской записью тормоза есть? Может вопрос в объёме данных?

[Tony Green]

Данных в таблице - тысяч 20, под админской записью тормозов нет

[a33ik]

Советую снять данные по запросам с ролью и без профайлером. Это может ответить на вопрос и подсказать выход.

[lode]

по дате представление не сортируете?

[Tony Green]

Сортирую. Это вредно?

[lode]

Если объем выбираемых данных с расширением прав растет, то да.
Хотя у Вас под админской ролью тормозов нет... Это странно.
Попробуйте сортировать по другому полю.

Почему вредно:
Посмотрите на tsql скрипт по созданию вашей Filtered View (Filtered+"Имя сущности").
В нем для всех дат выполняется преобразование от UTC к локальному времени пользователя.
Его нельзя проиндексировать и работает оно, мягко говоря, не очень быстро.

[Konstantin Katsovich]

Цитата:

Сообщение от lode

Почему вредно:
Посмотрите на tsql скрипт по созданию вашей Filtered View (Filtered+"Имя сущности").
В нем для всех дат выполняется преобразование от UTC к локальному времени пользователя.
Его нельзя проиндексировать и работает оно, мягко говоря, не очень быстро.

То есть вы хотите сказать, что скорость выполнения Filtered View зависит от того какой запрос будут над ним выполнять?

Поясню

Select * from Filtered…

Select new_name from Filtered…

Для того что бы выполнить первый запрос SQL выполняет Filtered… потом запрос.
То же самое происходит и со вторым.
Данные второй запрос вернет быстрее, но выполнение Filtered.. будет не быстрее.
Поэтому скорость выполнения Filtered View одинаковое при прочих равных условиях.

Какая разница по какому полю я буду сортировать если всё равно SQL будет преобразовывать каждый раз поле дата в локальное время пользователя?
Или я не прав?

[lode]

Цитата:

Или я не прав?

Не правы

всё равно SQL будет преобразовывать каждый раз поле дата в локальное время пользователя

Не каждый, а только тогда, когда в запросе будет участвовать вычисляемое поле даты.

если я пишу:

select name from FilteredAccount order by createdon

то время ожидаемо будет больше, чем

select name from FilteredAccount order by createdonutc

[Konstantin Katsovich]

Цитата:

Сообщение от lode

Не каждый, а только тогда, когда в запросе будет участвовать вычисляемое поле даты.

Можно ссылку на это утверждение?

[lode]

Цитата:

Можно ссылку на это утверждение?

конечно
http://msdn.microsoft.com/en-us/library/ms191250.aspx
"..Their values are recalculated every time they are referenced in a query."

Зачем вычислять, если оно не надо?

[Konstantin Katsovich]

Цитата:

Сообщение от lode

конечно
http://msdn.microsoft.com/en-us/library/ms191250.aspx
"..Their values are recalculated every time they are referenced in a query."

Я это понимаю немного по-другому. ( но оставим это пока).

Обращение к полям view происходит по слову(имени view) Filtered…
В имени view не написано какие поля вычислять а какие нет, поэтому мне кажется что выполняется вычисление всех полей. (поэтому эти views такие медленные.)

Ваше утверждение говорит о том, что SQL заменяет мой запрос своим да и ещё меняет запрос во view, что бы не вычислять поля которые не нужны при возврате.
Я Вас правильно понял?

[lode]

Цитата:

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

вобщем можно и так сказать...

вы возьмите простой пример - где нибудь на тестовой базе создайте представление:

create view t
as
select
	s.a,
	s.b,
	s.a/s.b ratio
from 
( 
	select 1 a, 2 b union all
	select 2 a, 0 b
) s

и поделайте select-ы к нему. Сразу станет понятно, когда он вычисляет все поля