Доброго дня, коллеги!
Уже по одной формулировке вопроса можно понять: сегодня у нас на повестку дня вынесен один из фундаментальных вопросов, связанный не только со сдачей экзамена 1С:Специалист по платформе 1С:Предприятие 8.3, но и в целом с проектированием архитектуры конфигурации.
Любой разработчик должен знать ответ на него :)
Вопрос
Сформулируем суть вопроса без погружения в конкретную формулировку задачи из сборника для подготовки к экзамену.
В тексте задачи представлена некая форма отчета, на ней есть поля (для простоты понимания нам даже не важно, какие). И вот некоторые слушатели задались вопросом. Как правило, регистры проектируются по принципу «один отчет – один регистр».
В решении, которое демонстрирует тренер, нет регистра (одного), который бы содержал в себе все необходимые данные для построения отчета. Так каким же образом планировалось строить отчет? Если мы будем строить отчет по нескольким регистрам, не нарушим ли мы требования экзамена?
Ответ
Принцип «один отчет – один регистр» – это первый шаг, начальная итерация, чтобы с чего-то начать решение задачи. Окончательное же решение может заметно отличаться от того, с чего начинали. Главное, чтобы решение в итоге было правильным. Часто также встречается рекомендация “один показатель – один регистр”, что, согласитесь, совсем не одно и то же.
Отчетов может быть довольно много и самых разных, делать на каждый из них отдельный регистр было бы нерационально. А вот имея набор регистров, в которых содержатся нужные для отчетов показатели, можно получить все требуемые в отчетах данные, комбинируя данные из нужных регистров и связывая их между собой. В рассматриваемой задаче из сборника, собственно, так и происходит. Даже если отчет один, то делать один универсальный регистр тоже не нужно – он может работать не оптимально. И рассматриваемая задача также иллюстрирует этот случай.
Если подвести итог одним словом, то, скорее всего, это слово «компромисс».
Если мы рассматриваем принцип «один отчет – один регистр», то подразумеваем проектирование одного большого регистра для всех данных отчета, что может быть не оптимально как по размеру, так и по производительности, особенно в многопользовательском режиме.
С другой стороны, если мы идем по пути «один показатель – один регистр», то в итоге можем получить множество мелких регистров, которые значительно усложнят разработку: сложнее в итоге построить отчеты, так как сложнее выбрать требуемые данные, сложнее алгоритмы проведения документов. Поэтому и при решении задач сборника, и при решении уже реальных задач нужно выбирать какое-то компромиссное взвешенное решение. Например, в качестве начальной итерации – один регистр на отчет. Затем по мере разработки разделить регистры в спроектированной схеме или наоборот объединить их.
Ну и напоследок, если вернуться к экзамену специалиста, то нащупать эту тонкую «компромиссную» грань на самом деле не так уж и сложно при условии, что вы методично будете прорешивать задачу за задачей, набивая руку в таком учебном проектировании.
Кстати, коллеги! Сертификат Специалиста по платформе – это хорошо, но как подобного рода задачи вы решаете в реальной практике? Ведь, скорее всего, те из вас, кто уже работает разработчиком, также сталкиваются с подобного рода дилеммой? Какими принципами руководствуетесь лично вы, решая подобные задачи? Может, поделитесь в комментариях? :)
Подготовка к аттестации 1С:Специалист по платформе 1С:Предприятие 8.3.