При проектировании и кастомизации решений на платформе «1С:Предприятие 8» разработчики часто задаются вопросом: почему в подавляющем большинстве типовых конфигураций (например, в «1С:Бухгалтерии предприятия») на счетах регистров бухгалтерии предусмотрено максимум три субконто? Кажется, что бизнес-требования могут требовать более глубокой аналитики — четырех, пяти или даже шести разрезов учета на одном счете. Однако разработчики фирмы «1С» жестко придерживаются правила «трех субконто». Если для управления бизнесом требуется больше аналитических разрезов, выполняется переход с 1С:Бухгалтерии 3.0 на 1С:Комплексную автоматизацию 2.
В этой статье мы подробно разберем, какие жесткие технические ограничения СУБД, особенности платформы «1С:Предприятие» и методологические правила диктуют именно такое ограничение. Мы выясним, почему попытка добавить четвертое и последующие субконто может критически замедлить работу всей системы.
Для того чтобы понять природу ограничения, нам необходимо спуститься на уровень хранения данных в СУБД (например, MS SQL Server). В сообщениях разработчиков часто упоминается ограничение MS SQL Server на максимальное количество полей в одном составном индексе — не более 16 полей. Давайте детально разберем, как связаны субконто в 1С и физические поля таблиц базы данных. Для исследования физической структуры и сопоставления метаданных 1С с таблицами СУБД можно использовать инструмент для просмотра внутренней структуры БД и анализа SQL-запросов.
Субконто в регистре бухгалтерии реализуются через механизм субконто планов счетов, который, в свою очередь, базируется на объекте ПланВидовХарактеристик. На уровне базы данных субконто — это реквизиты с составным типом данных. Физическое представление составного типа в СУБД зависит от того, какие именно типы разрешены для данного субконто:
_Fld..._TYPE);_Fld..._RTRef);_Fld..._RRRef / UUID).Проанализируем так называемый эффект «страйка» (худший сценарий). Представим, что для субконто разрешены ссылочные типы данных и четыре примитивных типа (строка, число, дата, булево). Для хранения всего одного такого субконто в таблице СУБД будет создано 7 полей (3 поля для ссылки + 4 поля для примитивных типов)!
Теперь вспомним структуру составного индекса регистра бухгалтерии, в который должны входить:
Если на регистре бухгалтерии настроено три субконто, каждое из которых способно хранить составные типы данных, количество полей в индексе вплотную приближается к критическому лимиту в 16 полей или даже выходит за него. Добавление четвертого или пятого субконто гарантированно приводит к превышению лимита СУБД MS SQL Server. В этом случае поля, не поместившиеся в индекс, просто не будут в него включены. При выполнении запросов с отбором по непоместившимся субконто СУБД не сможет использовать индексный поиск (Index Seek) и перейдет к полному сканированию таблицы (Table Scan) или дорогостоящему поиску перебором, что мгновенно парализует производительность системы при росте объемов данных.
Выясним, как ведет себя современная платформа «1С:Предприятие 8.3» при выходе за пределы 15 индексируемых полей. Разработчики платформы внедрили обходной механизм, призванный предотвратить аварийную остановку системы:
Рассмотрим подробнее, почему хэш-индекс не является полноценным решением проблемы. Хэш-функция позволяет выполнять поиск только по точному равенству. Если в вашем запросе или отчете используется условие диапазона (например, выборка данных за период), сравнения «больше/меньше», сортировки или группировки, хэш-индекс становится абсолютно бесполезным. СУБД будет вынуждена считывать все записи с диска и фильтровать их в оперативной памяти. Таким образом, быстродействие системы при сложных аналитических выборках критически падает.
Производительность отчетов в 1С напрямую зависит от скорости работы виртуальных таблиц регистра бухгалтерии (Остатки, Обороты, ОстаткиИОбороты). Платформа хранит рассчитанные итоги в СУБД в разрезе количества субконто, заданных для конкретных счетов:
UNION) или соединения (JOIN) между разными физическими таблицами итогов. Чем больше счетов с разным количеством субконто участвует в запросе, тем сложнее становится план запроса СУБД.Посмотрим на пример классического запроса к виртуальной таблице остатков:
// Пример получения остатков по счету с использованием отбора по видам субконто
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ХозрасчетныйОстатки.Субконто1 КАК Контрагент,
| ХозрасчетныйОстатки.Субконто2 КАК Договор,
| ХозрасчетныйОстатки.СуммаОстаток КАК ОстатокДолга
|ИЗ
| РегистрБухгалтерии.Хозрасчетный.Остатки(
| &Период,
| Счет = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.РасчетыСПокупателями),
| ,
| Организация = &Организация
| ) КАК ХозрасчетныйОстатки";
Если на счете «Расчеты с покупателями» будет добавлено 4-е или 5-е субконто, время построения этой виртуальной таблицы и выполнения соединений на уровне СУБД увеличится в геометрической прогрессии.
Проанализируем ситуацию с записью данных. Проведение документов — это интенсивный процесс записи в регистры. При записи каждой проводки платформа выполняет следующие действия:
Каждое дополнительное субконто увеличивает вариативность уникальных комбинаций аналитики. Это приводит к существенному раздуванию таблиц итогов. На уровне СУБД обновление индексов по широким таблицам требует наложения монопольных блокировок. В многопользовательских базах с высокой интенсивностью транзакций добавление даже одного «лишнего» субконто на активно используемые счета (например, счета учета затрат или товаров) гарантированно приводит к частым взаимным блокировкам (Deadlocks) и ошибкам ожидания блокировок СУБД. Для оценки влияния избыточных субконто на физический размер БД можно использовать инструмент для анализа размера таблиц и отдельных полей MS SQL.
Помимо чисто технологических ограничений СУБД, существует огромный пласт прикладного кода. Все стандартные отчетовы («Оборотно-сальдовая ведомость», «Анализ счета», «Карточка счета» и другие) в типовых конфигурациях 1С изначально спроектированы под работу с тремя субконто.
В отличие от старой платформы «1С:Предприятие 7.7», где добавление субконто приводило к автоматическому разбуханию итогов по всем счетам базы данных, платформа «1С:Предприятие 8» хранит итоги более изолированно. Тем не менее, алгоритмы компоновки данных, формы настроек отчетов и макеты жестко завязаны на вывод трех аналитик (Субконто1, Субконто2, Субконто3). Если вы добавите на какой-либо счет четвертое субконто, вам придется вручную переписывать и кастомизировать практически всю стандартную и регламентированную отчетность компании.
С точки зрения правильной архитектуры систем автоматизации на платформе 1С, попытка уместить всю аналитику компании в регистр бухгалтерии признана грубой ошибкой проектирования. Проанализируем правильное разделение контуров учета:
Правильно спроектированная система отражает хозяйственную операцию детально в оперативном контуре (на регистрах накопления), а в бухгалтерский регистр передает лишь агрегированную проводку, фиксирующую финансовый факт. При необходимости детальной расшифровки отчеты должны обращаться к регистрам накопления, связывая их данные с бухгалтерскими итогами. Такой подход гарантирует максимальную производительность, масштабируемость системы и отсутствие блокировок при одновременной работе сотен пользователей. В ситуациях, когда бухгалтерский контур необходимо выделить из сложной системы в отдельную базу, используется перенос данных из 1С:ERP 2 в 1С:Бухгалтерию предприятия 3.0.