О динамических отображаемых именах сущностей

[igla]

Приветствую!

Вопросик по CRM 4.0 (хотя, думаю, он актуален и для предыдущих версий)...

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

Теперь допустим, что нужно динамически формировать отображаемое имя объекта на основании значений нескольких его атрибутов (типа склеить ФИО из фамилии, имени и отчества человека). ОК, это тоже понятно - пишем javascript на событии OnChange каждого из полей, являющихся составными частями отображаемого имени, который склеивает их в одно большое ФИО.

А теперь, собственно, вопрос. Допустим, что нужно динамически формировать отображаемое имя объекта на основании значений как его атрибутов, так и атрибутов связанных с ним объектов (а возможно - и связанных со связанными). Причем значения этих атрибутов могут меняться в течении их жизни в системе (например, смена фамилии).

Как это реализовать?

Вариант 1 - написать огромное количество плагинов на Create, Update и Delete всех сущностей, от атрибутов которых зависит отображаемое имя данной сущности, дабы в них перегенерировать отображаемое имя.
Минус - неоправданно (на мой взгляд) большой объем кода, чуть ли ни экспоненциально растущий при росте количества связанных сущностей.

Вариант 2 - CRM не предназначен для решения подобных задач, нужно придумать другую модель классов, в которой этот вопрос не встанет.
Минус - не придумывается

Help!

[Гуревич Денис]

Вообще-то, задача сама по себе - бред, и идет вразрез с реляционной моделью данных.
Но все равно могу предложить 3-й вариант:
Втыкаете на CRM-сервере самописную Windows-службу, которая с некой периодичностью (раз в день, час, минуту) пробегается по Вашим объектам и генерит (при необходимости) новое отображаемое имя.
Плюсы - весь код сосредоточен в одном месте.
Минусы - при большом количестве объектов длительное время обработки; какое-то время имя может быть неактуальным.

[igla]

Цитата:

Сообщение от Гуревич Денис

Вообще-то, задача сама по себе - бред, и идет вразрез с реляционной моделью данных.
Но все равно могу предложить 3-й вариант:
Втыкаете на CRM-сервере самописную Windows-службу, которая с некой периодичностью (раз в день, час, минуту) пробегается по Вашим объектам и генерит (при необходимости) новое отображаемое имя.
Плюсы - весь код сосредоточен в одном месте.
Минусы - при большом количестве объектов длительное время обработки; какое-то время имя может быть неактуальным.

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

По поводу бреда и реляционной модели - я, видимо, не очень хорошо описал задачу...

Вот условный пример.

Есть сущности Личность (атрибуты Фамилия, Имя, Отчество и вычислимый ФИО, который является отображаемым именем) и, скажем, Сотрудник (связь с Личностью N:1, атрибуты Статус и Должность). Какое отображаемое имя выглядит логичным для объекта сущности Сотрудник? Наверное что-то типа "<Должность> <ФИО связанной Личности> (<Статус>)", т.е. "слесарь Иванов Иван Иванович (уволен)".

Вполне укладывается и в реляционную модель, и в реальную жизнь, не правда ли?

[Гуревич Денис]

Неправда!
В реляционной модели полностью исключается дублирование данных.
Дублирование создает потенциальные возможности рассогласования данных.

В данном случае гораздо правильнее создать собственное приложение, отображающее связанные данные и встроить его в CRM.

[igla]

Цитата:

Сообщение от Гуревич Денис

Неправда!
В реляционной модели полностью исключается дублирование данных.
...

Вооот, дык и я о том же - отображаемое имя объекта Сотрудник должно (по уму) быть вычислимым в момент обращения, а не храниться где-то на постоянной основе.
Свое приложение, безусловно, даст такую возможность.


Я, собственно, хотел получить подтверждение тому, что в моем условном примере:
1) статическое отображаемое имя, которое приводит к сложносинхронизируемым избыточным данным, использовать нерационально;
2) динамическое (вычислимое в момент обращения) отображаемое имя средствами CRM сделать невозможно.

Все же если вдруг кто-нибудь решал сходную задачу - с удовольствием почитаю, каким именно образом...

[maclai]

В 1с:8.0 подобная задача решается через вычисение значений полей из даных регистров с опорой на перечисления. Примером может послужить "вычисляемое" поле "адрес" в справочнике контрагентов. Посмотрите, однако сам я согласен с Денисом - СРМ не ЕРП, хлопотно это.

[sergeyjb]

Я не знаю как в CRM, но если касаться реляционной модели:

В вашей модели Сотрудник-Личность (N:1), в отображаемое имя сущности Сотрудника не корректно включать атрибут ФИО, т.к. у сущности Сотрудник нет такого атрибута. В вашей модели сущность Сотрудник это не более чем обезличеная должность со статусом и ВСЕ!

А та сущность отображаемое имя который вы хотите вывсести как "слесарь Иванов Иван Иванович (уволен)" это уже новая сущность над вашими двумя и в реляционной модели всегда реализовывалась в виде вьюшки. Делайте ее на базе обеих сущностей и вставляйте вычисляемы поля. И все!

В вашей модели будет избыточность по должностям. В идеале вам надо разбить сущность Сотрудник на 2: Должность и Сотрудник и итог будет таким:

Должность:
id_dolg
name_dolg

Сотрудник:
id_dolg
id_lich
status

Личность:
id_lich
fam
imya
otch

И связать их так:
Должность (1:N) Сотрудник (N:1) Личность

Над этими сущностями вьюшкой можно построить сущность которую использовать для бизнес-логики уже, например:

Штатная еденица:
Должность.name_dolg
Сотрудник.status
Личность.fio

И вот к этой сущности относить отображаемое имя "слесарь Иванов Иван Иванович (уволен)" будет корректно!

Это с точки зрения реляционной модели в чистом виде.
Как это все реализовать в CRM - думайте, спрашивайте тут у знающих...

[igla]

Спасибо за ответы.

sergeyjb, Вы все логично расписали. Если бы я решал эту задачу на ADO.NET или чем-то подобном, то пошел бы сходным путем самостоятельно и вряд ли стал бы беспокоить участников этого или какого-либо другого форума
Проблема в том, что в CRM нет ни вьюх, ни вычислимых полей, ни их аналогов...

Видимо, придется вовсе отказаться от сложного построения отображаемых имен.

[sergeyjb]

Самое обидное что СРМ то как раз и стоит всеми ногами на этих вьюшках и прочей реляционной братии.
Да вот только трогать их не моги а работай через интерфейс.
Может конечно и правильно - чтобы методологию не ломали и лишних сущностей разного уровня не создавали...