При изучении архитектуры современных типовых конфигураций, таких как 1С:Бухгалтерия предприятия 3.0, разработчики часто задаются вопросом: почему структура базы данных кажется «денормализованной»? Особенно ярко это проявляется в справочнике Номенклатура, где можно встретить десятки булевских реквизитов: Шины, Духи, Пиво, АльтернативныйТабак, МолочнаяПродукция и другие. С точки зрения классической теории проектирования реляционных баз данных, создание отдельной связанной таблицы (отношение «один ко многим») выглядит более правильным решением. Давайте вместе разберем причины, по которым архитекторы 1С выбрали именно такой путь, и проанализируем технические нюансы этого решения.
Одной из главных причин появления «раздутой» структуры справочника является скорость изменения российского законодательства. Система маркировки «Честный ЗНАК» вводилась поэтапно для разных групп товаров. Рассмотрим ситуацию: сегодня правительство подписывает постановление о маркировке новой категории товаров, а завтра программа уже должна уметь с ней работать. В таких условиях у разработчиков 1С нет времени на глобальный рефакторинг ядра системы.
Добавление нового булевского реквизита — это самый быстрый и безопасный способ расширить функционал, не нарушая работу существующих механизмов. Проанализируем цепочку событий: создание новой колонки в таблице БД позволяет мгновенно задействовать её в формах, отчетах и правилах обмена, не затрагивая логику работы других товарных групп.
Справочник Номенклатура является одним из самых высоконагруженных объектов в любой базе 1С. Он используется практически в каждом документе (от «Поступления товаров» до «Реализации»). С точки зрения производительности платформы 1С:Предприятие, чтение данных из одной таблицы всегда происходит быстрее, чем выполнение соединения (JOIN) с другой таблицей.
Разберем пример: если бы сведения о маркировке хранились в отдельном регистре сведений или подчиненном справочнике, то при каждом формировании динамического списка или при подборе товара в документ системе приходилось бы выполнять левое соединение. В базах с миллионами записей номенклатуры это привело бы к значительным задержкам. Использование булевских полей в основной таблице позволяет:
Огромное количество пользователей 1С используют кастомизированные конфигурации. Любое серьезное изменение структуры метаданных (например, перенос признаков из реквизитов в отдельную таблицу) может привести к поломке внешних обработок, отчетов и интеграций.
Посмотрим на ситуацию со стороны архитекторов: чтобы сохранить работоспособность стороннего кода, поля не удаляются и не переносятся мгновенно. Именно так появляются реквизиты с префиксами Удалить.... Выясним причину их существования: это промежуточный этап. Когда архитекторы всё же решают унифицировать данные (например, перенести их в перечисление ТипМаркировки), старые булевские поля помечаются на удаление, но остаются в структуре БД еще на несколько релизов, чтобы дать программистам время адаптировать свои решения.
В «1С:Бухгалтерии 3.0», которая позиционируется как массовый и относительно простой продукт, важно сохранять линейность настроек. Использование отдельных реквизитов позволяет легко привязывать к ним Функциональные опции. Рассмотрим, как это работает:
// Пример логики управления интерфейсом
Если Объект.Пиво Тогда
Элементы.ГруппаНастройкиПива.Видимость = Истина;
КонецЕсли;
Если бы данные хранились в связанной таблице, логика управления формой стала бы значительно сложнее, требуя дополнительных запросов к базе данных при открытии каждой карточки товара или при переключении между строками в списке.
Хотя нормализация — это стандарт для проектирования БД, в системах класса ERP и учетных решениях часто применяется подход «плоских таблиц» для ускорения чтения. В 1С создание связи «один ко многим» для простых признаков «да/нет» избыточно.
Проанализируем последствия: если для 100 000 позиций номенклатуры нужно хранить признак «Шины», создание 100 000 записей в подчиненном регистре сведений увеличит размер базы и замедлит операции индексации и тестирования/исправления (ТИБ). Одна колонка в основной таблице занимает значительно меньше места и обрабатывается SQL-движком эффективнее.
Стоит отметить, что разработчики 1С осознают проблему «раздувания» метаданных. В последних релизах БП 3.0 заметен тренд на использование более универсальных реквизитов. Например, вместо десятка новых флажков для новых видов товаров (например, антисептики или БАДы) всё чаще используется реквизит с типом ПеречислениеСсылка.ОсобенностиУчетаНоменклатуры.
Однако старые поля (Шины, Духи) остаются для поддержки исторических данных. Перенос данных из булевских полей в универсальное перечисление — это сложная процедура конвертации, которая должна пройти бесшовно у миллионов пользователей с разным уровнем технической поддержки.
Подводя итог, можно сказать, что обилие булевских полей в Номенклатуре — это не признак низкой квалификации архитекторов, а осознанный инженерный компромисс. В данном случае в жертву академической чистоте архитектуры принесены:
При проектировании собственных решений на платформе 1С нам следует помнить, что иногда «неправильная» с точки зрения теории архитектура оказывается единственно верной в условиях реальной эксплуатации и жестких внешних ограничений.