Получение кода виртуальной компании из SQL

[trud]

При постройке отчетов в SSRS(обычных, без расширений AX2009) столкнулись с проблемой получения кода компании по которой надо делать выборку данных. Пользователь при запуске отчета указывает код реальной компании, но часть таблиц включены в виртуальные компании т.е. по сути нужна какая-то функция, которая по имени таблицы и коду компании которую указал пользователь вернет или тот же самый код, или код виртуальной компании.
Сейчас приходит в говову только создание новой таблицы с 3 полями - имя таблицы, код компании, код виртуальной компании и периодическое ее обновление джобом.
может кто делал это более красиво?

[Владимир Максимов]

Существует системная таблица VirtualDataAreaList, которая содержит пары соответствия виртуальных и реальных компаний. Ее и можно использовать в запросах примерно таким образом.

tab1 - не виртуализирована
tab2 - виртуализирована

select *
from tab1
inner join tab2 on tab1.ID = tab2.ID --    
	--      
	and (tab1.dataAreaId = tab2.dataAreaId
		or exists(select 1 from VirtualDataAreaList vdal
			where vdal.virtualDataArea = tab2.dataAreaId
				and vdal.id = tab1.dataAreaId))

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

[Maxim Gorbunov]

Владимир, не усложняйте

trud, проблема известная, и Майкрософт даже писал о том, как её решать (примерно год назад). Вкратце: создайте View для таблиц, которые включены в виртуальную компанию, и используйте этот View в запросах. Подробности здесь: http://www.microsoft.com/downloads/e...c-802da5053a55

[trud]

Цитата:

Сообщение от Maxim Gorbunov

Вкратце: создайте View для таблиц, которые включены в виртуальную компанию, и используйте этот View в запросах.

Ну тут подразумевается, что я знаю эти самые таблицы, т.е. зашиваюсь на то, что никто ничего не изменит.
Спасибо всем, подходы понятны

[Maxim Gorbunov]

Если Вас это так пугает, создайте view вообще для всех таблиц, которые используются в SSRS-запросах. Тогда никакие изменения в системе на работе отчётов не отразятся. Они будут работать вне зависимости от того, включена таблица в виртуальную компанию или нет.

[Alexius]

Добавление таблиц трансляции компании в запрос (в т.ч. и в виде вьюх) ухудшает план выполнения запросов. такой подход увеличивает и универсальность и время выполнения. Таблицы "завиртуаленные" для всех компаний лучше вообще "лишать" признака компании (SaveDataPerCompany = No).

[Maxim Gorbunov]

На счёт того, что это лучше - спорно. Всё-таки, от значительной части функциональности при этом отказываться приходится. Я бы это предложение сформулировал так: если возникают проблемы с производительностью, рассмотрите вариант с использованием SaveDataPerCompany = No вместо виртуальных компаний.

[Alexius]

Цитата:

Сообщение от Maxim Gorbunov

На счёт того, что это лучше - спорно. Всё-таки, от значительной части функциональности при этом отказываться приходится.

А можно поподробнее, от какой части функциональности придется отказаться ?
Из известных мне минусов:
1. Могут быть проблемы с таблицами завязанными на Интеркомпани (они так же проявляются и при отсутствии лиц. ключа).
2. Большое кол-во "прямых SQL" запросов уже настроенных на работу с виртуальной компанией.

Цитата:

Сообщение от Maxim Gorbunov

Я бы это предложение сформулировал так: если возникают проблемы с производительностью, рассмотрите вариант с использованием SaveDataPerCompany = No вместо виртуальных компаний.

Иногда лучше предотвратить возникновение проблемы, чем разбираться с ее последствиями

[Maxim Gorbunov]

Извините, но поподробнее - в мануалах. Виртуальные компании сами по себе тоже являются полезной функциональностью.

[MikeR]

Кстати, а почему не используете, отчеты с расширением Dynamics Ax, там ведь можно делать достаточно расширяемые решения. Например