Последствия добавления relation на существующую таблицу

[kitty]

Есть таблица. В ней поле DefaultDimension. У поля EDT LocalRecId, relation по этому полю к DimensionAttributeValueSet на таблице нет
Если пользователь в запросе накладывает на эту таблицу условия, то поля из DimensionAttributeValueSet не появляются (тк нет relation). Обычно ядро автоматичски создает поля типа Dimension.Customer, Dimension.CustomerRegion etc
Мне нужно дать пользователю взможност фильтровать по fin dimensions, поэтому добавила relation.
Вопросы:
1) Какие могут быть последствия для существующего функционала? В коде я вижу только заполнение простым присваиванием этого поля из другой таблицы, на что relation по идее не должен повлиять.
2) Можно ли добавить фильтр по fin dim как-то иначе?
Пробовала сделать через запрос, т.е создат ь AOT->Query и добавить к моей таблице join к DimensionAttributeValueSet в , но по-моему для fin dimensions ядро хитро обрабатывает fin dim связи и поэтому полей в фильтре не появлется (или я что-то не так делаю)

[Link]

Цитата:

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

Вопросы:
1) Какие могут быть последствия для существующего функционала? В коде я вижу только заполнение простым присваиванием этого поля из другой таблицы, на что relation по идее не должен повлиять.
2) Можно ли добавить фильтр по fin dim как-то иначе?
Пробовала сделать через запрос, т.е создат ь AOT->Query и добавить к моей таблице join к DimensionAttributeValueSet в , но по-моему для fin dimensions ядро хитро обрабатывает fin dim связи и поэтому полей в фильтре не появлется (или я что-то не так делаю)

Если таблица используется где то еще, то добавление нового релейшена может повлиять на существующий функционал. Перед добавлением будет не лишним проанализировать поля из релейшена. Если релейшен нужен в какой то кастомной\единственной форме, то возможно будет оправданно прописать его в коде, а не создавать на таблице. С другой стороны когда релейшн на таблице, то он будет автоматически использоваться. Так что все зависит от самого релейшена и его использования.

[kitty]

То, что изменение существующих объектов может повлиять на функционал и так понятно, иначе б вопрос не возник. Хотелось бы конкретики.
+ Есть предложения, как можно добавить фильтр (в форму фультрации, чтобы пользователь мог наложить условия перед запуском функционала) по fin dim таблицы, не создавая relation?

[sukhanchik]

Цитата:

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

но по-моему для fin dimensions ядро хитро обрабатывает fin dim связи и поэтому полей в фильтре не появлется (или я что-то не так делаю)

Вся хитрость заключается в том, чтобы метод \Classes\SysDictType\isDimension
вернул бы истину. А для этого EDT у Вашего поля - должен быть одним из тех, что перечислены в этом методе.

[Raven Melancholic]

В DAX2012 релейшены по феншую определяются на таблице.
Вроде бы это по описанию было сделано для устранения противоречий. Но, опять же, если есть несколько релейшенов, противоречащих друг другу, то порядок их применения ничем не отличается от предыдущих версий - то есть, совершенно не определен. Как эти релейшены сработают можно проверить только на конкретных данных.
Как уже сказали мои коллеги, вполне возможно, что управлять релейшенами придется из кода. Вполне возможно, что сработают релейшены, заданные декларативно, но есть большая вероятность, что в случае одинаковых релейшенов Акса не сможет выбрать нужный и придется делать "закат солнца вручную", прописывая в коде реакцию на связи.

[Raven Melancholic]

Вообще, если учесть подход в DAX2012, что "нормализация данных это наше все" релейшены это не самое сложная вещь. Ещё ни раз придется столкнуться с тем, что раньше что-то делали простым указанием что и как связано, в DAX202 придется это прописывать в коде.