Вебинар по функциональности Электронной отчетности (Electronic reporting) и Электронных сообщений (Electronic messages)

[axm2017]

Цитата:

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

...то по mapping у нас была неправильная рекомендация стараться жить с одним mapping лишь дорабатывая его. Как показала практика жить на одном mapping пытаясь не сломать существующее модифицировать основываясь на других источниках данных крайне сложно и не стоит усилий. Проще сделать новый mapping...
Чуть попозже попробую проиллюстрировать примером.

Проиллюстрирую возникающую проблему с рекомендацией.
Предположим у нас есть все из примера 1 и это всем нравится до такой степени что китайские сотрудники попросили запилить почти такой же отчет.
Ок. Не вопрос. Делаем почти такой же формат.
Но китайские товарищи к примеру начинают хотеть порой свое уникальное значение в поле идентификатор так как мое их не устроило (из другого источника данных связанного с табличкой).
Попытки решить подобное изначально в рамках одного mapping (типа добавим поле IdFromChine и прочее) оказались крайне неудобными. Отчеты и модели жили своей жизнью росли, покрываясь расчетными функциями и прочим и это же касалось mapping (где надо было помнить еще и о китайцах) в итоге поддержка подобной уникальности оказалась трудозатратной.

Проще оказалось сделать новый mapping хотя изначально рекомендовалось жить в одном маппинге.

[belugin]

Цитата:

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

Попытки решить подобное изначально в рамках одного mapping (типа добавим поле IdFromChine и прочее) оказались крайне неудобными.

Чем?

[axm2017]

Цитата:

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

Чем?

По факту у нас есть ID для китайских и отдельно для обычных людей.

Какие есть варианты действий?

1. Добавить в модель поле китайский ID.
А потом индийский. А потом выслушать обвинение в расизме от консультанта почему китайский ID идет отдельно (типа ты их за людей не считаешь?).

2. Добавить заполнение ID на маппинге для китайцев свое, а для обычных свое. Ок вводим функцию определитель страны и в зависимости от нее заполняем ID. Но так как в реальности появляется куча наворотов + еще и индийцы то все становится тяжелым и не все помнят о существовании китайских коллег. Есть высокая вероятность что кто то сломает им все, правя для себя. В общем пришли к тому что надо разделять маппинги.

[belugin]

Цитата:

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

1. Добавить в модель поле китайский ID.
А потом индийский. А потом выслушать обвинение в расизме от консультанта почему китайский ID идет отдельно (типа ты их за людей не считаешь?).

Это реальный кейз уже были такие претензии? Почему именно китайский идентификатор не такой как у всех? Если это требование какого-то стандарта типа IBAN, то вполне можно назвать его ID_<название стандарта>. Например, в ISO20022 к банкам привязано множество пар (схема идентификации, значение), где схема идентификации - это как раз разновидность такого стандарта.

Стандарты можно не считать за людей

[axm2017]

Цитата:

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

Это реальный кейз уже были такие претензии?

Это адаптированный под тестовый пример вариант проблемы. Но проблема практическая.

Цитата:

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

Почему именно китайский идентификатор не такой как у всех?

Это риторический вопрос? Мог быть индийский, итальянский и далее по вкусу. Тараканы у всех свои. Это хорошо заметно если модифицировать ssrs отчёты.

[belugin]

Цитата:

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

Это адаптированный под тестовый пример вариант проблемы. Но проблема практическая.

Мне из адаптированного тестового примера непонятно, чем именно неудобно добавить дополнительное поле.

Цитата:

Это риторический вопрос?

Нет.

Цитата:

Мог быть индийский, итальянский и далее по вкусу. Тараканы у всех свои. Это хорошо заметно если модифицировать ssrs отчёты.

Я просто хочу понять происхождение и свойства конкретного таракана чтобы понять чем именно это неудобно в конкретном случае.

[axm2017]

Цитата:

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

Мне из адаптированного тестового примера непонятно, чем именно неудобно добавить дополнительное поле.

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

Цитата:

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

Я просто хочу понять происхождение и свойства конкретного таракана чтобы чем именно это неудобно в конкретном случае.

В конкретном случае в 1 варианте количество полей в модели увеличилось в 1.5 раза а во втором выросла сложность и снизилась надёжность.

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