Штаны превращаются .... или как Fin dimension value без backing entity использовать как справочник.

[kitty]

Дали требование - нужна возможность связывать Item с несколькими значениями из конкретного Fin dimension "Тип работ". Тк связь 1:n. (Один и тот же тип работ не может быть связан с несколькими item) , то очевидным было бы решение - добавить поле ItemId на Тип работ, но ....у этого dimension нет справочника (backing entity) и клиент отказывается его заводить.
Поэтому либо нужно добавлть лишнее поле на DimensionFinancialTag, но это не очень хорошо.... Либо нужно создавать отдельную табличку связей и relation на этот dimension....delete action... , что тоже не фонтан ....

Есть ли альтернативные, может, варианты?

[Ivanhoe]

Почему отказывается? Ну т.е. сделать справочник и привязать аналитику к нему - это правильный подход. Не делать и пилить формы/связи - это совсем какой-то обходной путь - ради чего?

[kitty]

Предложила - отказались. Как я понимаю: не хотят, тк система уже рабочая. То есть, эти значения аналитик уже используются.
А то, что попросили сделать - это доработка, поэтому рисковать не хотят, тк потребуется перебивать данные в новый справочник, привязывать к аналитике.... Я не консультант, поэтому не знаю, обоснованы ли их переживания

[Ivanhoe]

Если все равно программировать, может, оценить сколько займет поменять тип аналитики и джобом обновить связи?

[ax_mct]

Quote:

Originally Posted by kitty

Дали требование - нужна возможность связывать Item с несколькими значениями из конкретного Fin dimension "Тип работ". Тк связь 1:n. (Один и тот же тип работ не может быть связан с несколькими item) , то очевидным было бы решение - добавить поле ItemId на Тип работ, но ....у этого dimension нет справочника (backing entity) и клиент отказывается его заводить.
Поэтому либо нужно добавлть лишнее поле на DimensionFinancialTag, но это не очень хорошо.... Либо нужно создавать отдельную табличку связей и relation на этот dimension....delete action... , что тоже не фонтан ....

Есть ли альтернативные, может, варианты?

Самое логичное это таки создать отдельную табличку [ItemId, DimensionFinancialTag RecId]. 1:n. Вообще не вижу проблем так как все предельно стандартно.

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

[trud]

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

[kitty]

Как можно ограничить количество полей, показываемое автоматически в Reference group?
Если в таблицу добавить DimensionFinancialTag.RecId , то на форме в ReferenceGroup автоматически будут подтягиваться три(!) поля из альтернативного ключа CategoryValueIdx. Один из них - category - это recId, что для пользователя вообще никакого смысла не имеет видеть. (Таблица явно не заточена к использованию на формах ..... что настораживает, как тогда предполагается показывать значения, привязанные к конкретному аттрибуту? простая задача же по сути)

Тк на таблице DimensionFinancialTag все группы полей содержат три поля, то я так понимаю, что единственный способ ограничить количество полей, автоматически добавляемых на форму - добавить свою новую Field group, содержащую только Value и эту группу уже указать на форме в refrence group -> replacement Field Group. (на моей форме стоит фильтр по категории, поэтому мне нужна только одна колонка - со значениями конкретного атрибута ).
Можно ли как-то иначе, кроме как с помощью новой круппы полей на таблице, ограничить количество колонок в reference group? Как-то магически эти лишние две колонки на форме удалить вруную , например ......

PS: Какой-то бред, что на таблице DimensionFinancialTag уникальный индекс состояит из трех полей FinancialTagCategory, Value, Description. Хотя по логике, да и по методу findByFinancialTagCategoryAndValue очевидно, что двух полей достаточно

[ax_mct]

Использовать свое собственное EDT или просто RefRecId?
Никто на заставляет использовать свойство альтернативный ключ.

[kitty]

без reference group в refRecID мало толку,
тк весь форнт энд либо будет корявым (пользователь лукапы с recId открывать будет) либо надо самому писать "умные" лукапы, которые возвращают и recId и поле пользователю понятное .

Сделала через новую группу на таблице.

Вообще, эта корявая "нормализация" в печенках уже.
Чтобы привинтить список значений одного из аттрибутов мне потребовалось:
1) добавить фильтр в init формы по DimensionFinancialTag.category
2) переписать лукап, чтобы:
a) выпадающие данные тоже фильтровал по category
b) не показвал recId колонку Category (не должно ли это вообще делаться ядром по умолчанию, раз уж сурргатный ключ на category на DimensionFinancialTag ... )
3) сделать группу полей на таблице, чтобы на форму в reference Group одно поле добавлялось ядром , а не три.

и все это ради того. что по сути можно было бы одним relation на таблице или edt раньше сделать....