Существуют ли шаблонные пути реализации таких требований?

[Romb]

Цитата:

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

вы вообще или про Аксапту?
и почему говорите только про формы? а отчеты? а кубы? а права? а полнотекстовый поиск? а импорт/экспорт? aif? а excel addon для редактирования данных?

Mazzy, спасибо за комментарий, не совсем понимаю что на него отвечать, я просто поясню свою позицию.

I. Тут присутствует работа с требованиями (RM).

Приведенные требования:

Цитата:

При создании заказа по умолчанию он наследует эти же 6 характеристик от клиента, но можно указать другие или удалить некоторые и тд.

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

В требованиях не написано ничего о кубах, отчетах, EDI и т.д.. Можно самостоятельно расширять дерево функциональности за заказчика, придумывать за него требования, но применительно к характеристикам обсуждены и предложены всего два сценария "указать другие" и "удалить некоторые", с предусловием "при создании заказа". (и, очевидно, что будут свои требования на обработку граничных условий, например "у клиента изменились характеристики, в этом случае характеристики у уже созданных заказов на этого клиента должны быть изменены...").

II. Дизайн.
1. Появляется одна новая сущность "Характеристика" с отношением "один ко многим" к сущностям "Заказ" и "Клиент".
2. Схему данных тут надо делать так: 1. Создать таблицу "Характеристики". 2. Создать таблицу "Наборы характеристик", которая и будет реализовывать связь с Характеристик с Заказами и Клиентами.
3. В случае с добавлением 6-и полей схема данных просто не будет нормализована. Это, например, выльется в т.ч. в явные проверки в коде по этому количеству полей, или, как минимум постоянные проверки на соответствие типов-массивов в разных таблицах и циклы по перебору этих полей в соответствии с размерностью типов. В это же время, при схеме данных из варианта №2, код будет написан один раз для любого количества характеристик.

III. Кодирование. Не думаю, что правильно применять тут оценки "в этом случае работы программисту больше/меньше". Последнюю оценку может давать только конкретный специалист-исполнитель. Но, важным ключом к количеству работы программиста является эффективность схемы данных, даже в такой небольшой задаче. Поэтому, надо придерживаться приоритетов при выполнении работы: 1) Утвердили требования (сценарии) 2) Смоделировали сущности 3) Смоделировали нормализованную схему данных. 4) Кодируем логику.

Прошу извинить за объем комментария, у меня нет цели вступить в спор/обсуждение. Буду рад, если моя аргументация окажется кстати, или некстати. Главное же результат.