Сколько карточек товаров может содержать справочник номенклатуры в 1С

Справочник «Номенклатура» — одна из самых нагруженных таблиц в любой конфигурации 1С: в нём хранятся карточки товаров, услуг и материалов. На практике жёсткого программного лимита на количество элементов в справочнике нет: платформа 1С:Предприятие 8 технически позволяет хранить миллионы записей. Реальное ограничение определяется не платформой, а производительностью сервера, типом СУБД, объёмом связанных данных (цены, штрихкоды, остатки) и тем, как организована работа пользователей.

Для небольшой компании справочник в 5–20 тысяч позиций работает без каких-либо проблем даже в файловом варианте базы. Торговые компании с широким ассортиментом спокойно эксплуатируют номенклатуру в 100–500 тысяч карточек на клиент-серверной архитектуре. Известны внедрения, где справочник содержит несколько миллионов позиций — но такая работа требует грамотной настройки СУБД, индексов и регламентного обслуживания.

Поэтому корректный вопрос звучит не «сколько карточек влезет», а «при каком объёме начнутся проблемы и как их избежать». Ниже разберём технические ограничения платформы, признаки перегрузки справочника, способы оптимизации и типичные ошибки, которые приводят к «тормозам» даже на умеренных объёмах данных.

Технические ограничения платформы 1С

В платформе 1С:Предприятие 8 справочники хранятся в таблицах СУБД, и количество элементов ограничено в первую очередь возможностями самой базы данных. Для клиент-серверного варианта (MS SQL Server, PostgreSQL, Oracle) предел измеряется миллиардами строк и упирается в дисковое пространство и ресурсы сервера, а не в логику 1С.

Единственное формальное ограничение, о котором стоит знать, — длина кода элемента справочника. По умолчанию в типовых конфигурациях код номенклатуры имеет длину 9–11 символов, что при числовом коде даёт до миллиарда и более уникальных значений. Если код используется как префиксо-зависимый или содержит буквы, ёмкость ещё выше. Исчерпать такой диапазон на практике практически невозможно.

В файловом варианте базы действует ограничение на размер одной таблицы — 4 ГБ. Сама таблица справочника редко достигает этого объёма, но связанные таблицы (например, регистры цен или история изменений) могут приблизиться к пределу, и тогда база просто перестанет принимать новые данные. Это одна из причин, по которой при росте номенклатуры рекомендуют переходить на клиент-серверную архитектуру.

Что реально замедляет работу при большом количестве карточек

Замедление работы почти никогда не связано с самим фактом существования большого числа карточек. Проблемы возникают из-за того, как с этими данными работают пользователи и механизмы конфигурации. Основные источники нагрузки — открытие полного списка справочника без отборов, поиск подстрокой по наименованию, динамические списки с соединениями к регистрам остатков и цен.

Второй фактор — связанные данные. На каждую карточку товара приходятся записи в регистрах цен, штрихкодов, остатков по складам, характеристик и серий. Справочник в 200 тысяч позиций может означать десятки миллионов строк в связанных таблицах, и именно они нагружают СУБД при проведении документов и формировании отчётов.

Третий фактор — дублирование и «мусор». В базах, куда номенклатура загружается из внешних источников без контроля, нередко 20–40% карточек — это дубли, устаревшие или никогда не использовавшиеся позиции. Они раздувают индексы, замедляют поиск и мешают пользователям выбирать правильный товар.

Как определить, что справочник перегружен

Есть несколько наблюдаемых признаков, по которым можно понять, что объём номенклатуры начал влиять на работу системы. Первый — заметная задержка при открытии списка справочника и при подборе товара в документы. Если форма подбора открывается дольше нескольких секунд, это повод для диагностики.

Второй признак — медленный поиск по наименованию или артикулу, особенно при вводе части слова. Третий — рост времени проведения документов поступления и реализации, поскольку при проведении обращаются регистры, связанные с номенклатурой. Четвёртый — увеличение размера базы и времени резервного копирования.

Для точной оценки используйте штатные инструменты: замер производительности через функциональность «Техножурнал» на сервере 1С, анализ длительных запросов средствами СУБД (например, план выполнения запросов в MS SQL Server Management Studio). Эти данные покажут, какие именно обращения к данным создают основную нагрузку.

Контрольные точки

Как проверить состояние справочника

Время открытия списка номенклатуры

Норма

До 1–2 секунд

Тревожный признак

Более 5 секунд или зависание формы

Поиск товара по части наименования

Норма

Результат за 1–3 секунды

Тревожный признак

Поиск занимает десятки секунд

Доля неиспользуемых позиций

Норма

Менее 10% карточек без движений

Тревожный признак

Значительная часть позиций без единого документа

Размер базы и время бэкапа

Норма

Стабильный, предсказуемый рост

Тревожный признак

Резкий рост, бэкап не укладывается в регламент

Как оптимизировать работу с большой номенклатурой

Оптимизация начинается с наведения порядка в данных. Проведите ревизию справочника: найдите дубли по наименованию, артикулу и штрихкоду, объедините их штатной обработкой «Поиск и удаление дублей» (в типовых конфигурациях она есть в разделе администрирования). Позиции, по которым нет и не будет движений, пометьте на удаление или перенесите в отдельную папку «Архив».

На уровне СУБД убедитесь, что выполняется регулярное обслуживание: обновление статистики, перестроение или реорганизация индексов. В клиент-серверном варианте это настраивается планами обслуживания SQL Server или заданиями для PostgreSQL. Без актуальной статистики оптимизатор запросов выбирает неэффективные планы, и даже мощный сервер будет «тормозить».

На уровне конфигурации полезно ограничить динамические списки: убрать из форм подбора лишние колонки и соединения с регистрами, настроить отборы по умолчанию (например, только актуальные товары), использовать иерархию и папки вместо плоского списка. Если поиск по наименованию критичен, рассмотрите полнотекстовый поиск платформы — он заметно ускоряет подбор при больших объёмах.

1. 1
   Сделайте резервную копию базы перед любыми массовыми изменениями
2. 2
   Найдите и объедините дубли штатной обработкой поиска дублей
3. 3
   Пометьте на удаление позиции без движений и выполните удаление помеченных объектов
4. 4
   Настройте регламентное обслуживание СУБД: обновление статистики и реиндексацию
5. 5
   Ограничьте динамические списки в формах подбора, уберите лишние соединения
6. 6
   Включите полнотекстовый поиск, если пользователи ищут товары по части наименования
7. 7
   Повторно замерьте время открытия списка и поиска — сравните с исходными значениями

Файловая или клиент-серверная база: как выбрать при росте номенклатуры

Файловый вариант подходит для небольших компаний: до 5–10 одновременно работающих пользователей и умеренного объёма данных. При таком сценарии справочник в несколько десятков тысяч позиций не создаёт проблем. Но по мере роста базы появляются риски: ограничение таблицы в 4 ГБ, блокировки при одновременной работе, уязвимость файла при сбоях.

Клиент-серверный вариант снимает эти ограничения: СУБД эффективно обрабатывает большие таблицы, поддерживает параллельную работу и даёт инструменты тонкой настройки. Переход оправдан, когда база заметно выросла, пользователей больше десятка, а операции с номенклатурой (загрузка прайсов, обновление цен, подбор товаров) стали занимать ощутимое время.

Сравнение вариантов работы

Файловая база

Подходит для небольшого ассортимента и малого числа пользователей; ограничение таблицы 4 ГБ и риск блокировок при росте

Клиент-серверная база

Подходит для сотен тысяч и миллионов позиций; требует лицензий на сервер 1С и СУБД, а также администрирования

Файловая база на терминальном сервере

Промежуточный вариант: снижает риск повреждения файла, но не снимает ограничения по объёму и блокировкам

Типичные ошибки при ведении большого справочника

Самая распространённая ошибка — бесконтрольная загрузка номенклатуры из прайсов поставщиков. Каждая загрузка без сопоставления создаёт новые карточки, и за год справочник может вырасти в несколько раз за счёт дублей. Вторая ошибка — отказ от иерархии: плоский список из сотен тысяч позиций неудобен и медленнее отображается.

Третья ошибка — хранение в карточке товара избыточных данных: длинных описаний, изображений высокого разрешения, множества дополнительных реквизитов без реальной необходимости. Это раздувает таблицу и замедляет выборки. Четвёртая — игнорирование регламентного обслуживания СУБД: индексы фрагментируются, статистика устаревает, и производительность деградирует постепенно и незаметно.

Частые вопросы о количестве карточек номенклатуры

Есть ли в 1С официальный лимит на количество товаров в справочнике?

Нет, официального лимита на число элементов справочника платформа не устанавливает. Ограничения косвенные: длина кода элемента (практически недостижимый предел), размер таблицы 4 ГБ в файловом варианте и ресурсы сервера в клиент-серверном.

Сколько карточек выдержит файловая база 1С?

Точного числа нет — всё зависит от объёма связанных данных и числа пользователей. На практике файловый вариант комфортно работает с десятками тысяч позиций. При приближении к сотням тысяч и росте базы стоит планировать переход на клиент-серверный вариант, не дожидаясь предела в 4 ГБ на таблицу.

Что будет, если в справочнике больше миллиона позиций?

Само по себе это не проблема для клиент-серверной базы: СУБД справляется с такими таблицами. Но потребуются настроенное обслуживание СУБД, продуманные формы подбора, полнотекстовый поиск и контроль дублей — иначе пользователи столкнутся с медленным открытием списков и поиском.

Можно ли удалить старые карточки товаров, чтобы ускорить базу?

Можно, но только позиции без ссылок в документах и регистрах. Используйте пометку на удаление и штатную процедуру «Удаление помеченных объектов» — она проверит ссылочную целостность. Позиции с движениями в закрытых периодах удалять нельзя: это нарушит отчётность за прошлые годы.

Влияет ли количество карточек на скорость проведения документов?

Напрямую — почти нет. На проведение влияют объёмы регистров остатков и цен, настройки итогов и индексов. Но косвенно большая номенклатура ускоряет рост этих регистров, поэтому при большом ассортименте важно следить за регламентным обслуживанием и своевременно сворачивать старые данные.

Как быстро узнать, сколько карточек сейчас в справочнике?

Проще всего открыть список справочника «Номенклатура» и вывести количество строк через настройку списка или универсальный отчёт по справочнику без группировок. В клиент-серверной базе точное число строк можно получить запросом COUNT к соответствующей таблице средствами СУБД.