Как правильно добавить вид документа в существующий документ при объеме данных 30 миллионов записей?

Программист 1С v8.3 (Обычные формы) IT и автоматизация бизнеса
← На главную

Работа с базами данных, содержащими десятки миллионов записей, требует от разработчика 1С особого подхода. В данной статье мы разберем задачу добавления реквизита ВидДокумента в документ, который уже содержит 30 миллионов записей. Мы проанализируем, какой тип реквизита лучше выбрать и как избежать длительной блокировки системы.

Оценка проблемы реструктуризации

Когда мы добавляем реквизит в конфигуратор, платформа 1С пытается выполнить процедуру реструктуризации таблицы базы данных. Для таблицы с 30 миллионами строк это может означать часы или даже дни простоя системы, так как SQL-серверу потребуется перестроить физическую структуру таблицы. Рассмотрим, какие подходы помогут нам справиться с этой задачей:

  1. Минимизация простоя: При изменении структуры на больших таблицах, некоторые специалисты используют метод «подмены таблицы» на уровне SQL. Суть заключается в создании новой таблицы с нужным полем, переносе данных и переименовании объектов. Однако этот метод требует высокой квалификации и осторожности.
  2. Использование регистра сведений: Если вы хотите избежать изменения структуры основной таблицы, можно вынести реквизит в отдельный РегистрСведений. В качестве измерения вы указываете Ссылка на документ, а в качестве ресурса — ваш вид документа. Это позволяет наполнять данными регистр постепенно, не блокируя основной документ.
  3. Архивирование данных: Если 30 миллионов записей включают в себя исторические данные, к которым редко обращаются, можно рассмотреть создание нового документа для будущих операций, оставив старый документ в режиме «только чтение».

Выбор типа реквизита: Справочник или Перечисление?

Это ключевой вопрос при проектировании. Давайте сравним два подхода, чтобы понять, что будет эффективнее в долгосрочной перспективе.

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

Вариант 2: Справочник. Использование Справочника дает вам гибкость. Когда вам потребуется добавить новый вид операции, вы просто создаете новый элемент справочника в режиме «1С:Предприятие». Это не требует правки конфигурации и не вызывает реструктуризацию таблицы.

Итог: Если список видов документов потенциально может расширяться или меняться, выбирайте Справочник. С технической точки зрения на уровне SQL-хранилища для 1С тип ссылки (на справочник или перечисление) выглядит практически идентично, поэтому на производительность запросов тип ссылки влияет незначительно.

Пошаговое планирование внедрения

Разберем, как нам поступить в данной ситуации наиболее безопасно:

  1. Проанализируем динамику: Если список видов операций жестко задан и не изменится в ближайшие годы, можно использовать Перечисление. Если же вы предвидите новые виды продаж в будущем — смело создавайте Справочник.
  2. Подготовим структуру: Если мы все же решаем добавить реквизит в документ, убедимся, что на сервере достаточно свободного места для создания копии таблицы в процессе реструктуризации.
  3. Рассмотрим вариант с регистром: Если время простоя недопустимо, создадим независимый РегистрСведений. Это позволит нам развязать руки и не зависеть от тяжелой реструктуризации основного документа.

Технические аспекты хранения

Важно помнить, что 1С хранит ссылки на объекты в виде binary(16). Независимо от того, выбрали вы Справочник или Перечисление, объем хранимых данных в таблице SQL будет одинаковым. Это подтверждает, что выбор между ними — это вопрос методологии сопровождения системы, а не производительности чтения/записи.

Мы выяснили, что если вы хотите избежать постоянных правок конфигурации, Справочник является наиболее предпочтительным вариантом. Он позволяет добавлять данные «на лету», что критически важно при работе с большими базами данных, где каждое обновление структуры требует длительного времени и тщательного планирования.

Надеемся, эти рекомендации помогут вам принять верное архитектурное решение и успешно адаптировать вашу конфигурацию под новые требования бизнеса!

← На главную