|
13.11.2019, 08:53 | #1 |
Участник
|
-Неудобный интерфейс прежде всего.
Про крайне неудобную при большом объеме работ дизайн раб инструментов уже высказывался, но выскажусь еще раз: устаревшие и порой крайне неудобны с учетом что сейчас 19 год. Ни подсветки ни чего пока нет. Надеюсь MS снизойдет и сделает возможность расширения инструментов работы. С учетом что это еще формально закрыто от модификацией чужими командами, то иногда пока боль. Не такая как с SSRS, но есть. -Неустоявшаяся методология (часть полученных принципов были не совсем корректны) . Как понимаю есть ожидание, логичное вполне, совместимости версий моделей, маппингов. Если с model ок, то по mapping у нас была неправильная рекомендация стараться жить с одним mapping лишь дорабатывая его. Как показала практика жить на одном mapping пытаясь не сломать существующее модифицировать основываясь на других источниках данных крайне сложно и не стоит усилий. Проще сделать новый mapping. Отсутствует инструмент тестирования совместимости версий что не good как по мне. Чуть попозже попробую проиллюстрировать примером. ЗЫ кстати на всякий случай уточню что ER при всех недостатках мне нравится и выглядит предпочтительнее чем SSRS ( который к тому же вроде скоро умрет) в силу простоты, скорости и гибкости. |
|
13.11.2019, 12:27 | #2 |
Участник
|
Так как уровень читателя неизвестен то иногда прокомментирую что такое ER в моем понимании.
Начну с основы ER - система подготовки отчетности. Держится она на трех китах: Любой отчет это прежде всего какой то формат представления данных:word, excel, xml и т п. Поэтому один из китов - это формат отчетности. В отчете пользователь хочет увидеть какие то данные: например имя и идентификатор кого то. Представление пользователя о данных называют моделью. Понятно что модель и реальные данные системы это разные вещи порой и их надо как то соотносить. Для этого есть mapping. |
|
13.11.2019, 13:06 | #3 |
Участник
|
Вот пришел ко мне пользователь ака консультант и выдал традиционное:
axm2017 нужно срочно завтра-вчера сделать отчет в котором хочу увидеть: - имя пользователя -идентификатор пользователя а так как ты земляной червячок, в сравнении со мной, то твори это все сам. Задание модели 1 шаг Придумаем осмысленное название и создадим 2 шаг Далее жмем Designer и попадаем в режим просмотра/разработки модели, где создаем корневую структуру. 3 шаг Так как пользователей будет скорее всего не один то укажем что их будет много целый набор 4 шаг Укажем что у каждой записи есть два поля Идентификатор и Имя создав соответствующие свойства в пользователе Итого получим что то типа Сохраняем изменения скомплектовав модель (Change status) Ура мы создали тестовую модель. PS небольшие комментарии: надписи задаем либо как надписи либо метками. Метки у ER свои что позволяет задавать/исправлять перевод без лишних телодвижений. Последний раз редактировалось axm2017; 13.11.2019 в 13:21. |
|
|
За это сообщение автора поблагодарили: sukhanchik (6). |
14.11.2019, 16:56 | #4 |
Участник
|
Цитата:
Сообщение от axm2017
...то по mapping у нас была неправильная рекомендация стараться жить с одним mapping лишь дорабатывая его. Как показала практика жить на одном mapping пытаясь не сломать существующее модифицировать основываясь на других источниках данных крайне сложно и не стоит усилий. Проще сделать новый mapping...
Чуть попозже попробую проиллюстрировать примером. Предположим у нас есть все из примера 1 и это всем нравится до такой степени что китайские сотрудники попросили запилить почти такой же отчет. Ок. Не вопрос. Делаем почти такой же формат. Но китайские товарищи к примеру начинают хотеть порой свое уникальное значение в поле идентификатор так как мое их не устроило (из другого источника данных связанного с табличкой). Попытки решить подобное изначально в рамках одного mapping (типа добавим поле IdFromChine и прочее) оказались крайне неудобными. Отчеты и модели жили своей жизнью росли, покрываясь расчетными функциями и прочим и это же касалось mapping (где надо было помнить еще и о китайцах) в итоге поддержка подобной уникальности оказалась трудозатратной. Проще оказалось сделать новый mapping хотя изначально рекомендовалось жить в одном маппинге. Последний раз редактировалось axm2017; 14.11.2019 в 16:58. |
|
15.11.2019, 14:33 | #5 |
Участник
|
|
|
15.11.2019, 15:01 | #6 |
Участник
|
По факту у нас есть ID для китайских и отдельно для обычных людей.
Какие есть варианты действий? 1. Добавить в модель поле китайский ID. А потом индийский. А потом выслушать обвинение в расизме от консультанта почему китайский ID идет отдельно (типа ты их за людей не считаешь?). 2. Добавить заполнение ID на маппинге для китайцев свое, а для обычных свое. Ок вводим функцию определитель страны и в зависимости от нее заполняем ID. Но так как в реальности появляется куча наворотов + еще и индийцы то все становится тяжелым и не все помнят о существовании китайских коллег. Есть высокая вероятность что кто то сломает им все, правя для себя. В общем пришли к тому что надо разделять маппинги. |
|
15.11.2019, 17:09 | #7 |
Участник
|
Цитата:
Стандарты можно не считать за людей |
|
15.11.2019, 17:25 | #8 |
Участник
|
Это адаптированный под тестовый пример вариант проблемы. Но проблема практическая.
Это риторический вопрос? Мог быть индийский, итальянский и далее по вкусу. Тараканы у всех свои. Это хорошо заметно если модифицировать ssrs отчёты. Последний раз редактировалось axm2017; 15.11.2019 в 17:31. |
|
15.11.2019, 22:25 | #9 |
Участник
|
Цитата:
Цитата:
Это риторический вопрос?
Цитата:
Мог быть индийский, итальянский и далее по вкусу. Тараканы у всех свои. Это хорошо заметно если модифицировать ssrs отчёты.
|
|
Теги |
generic electronic reporting, ger |
|
|