Сколько таблиц используется для хранения констант?

Сколько таблиц используется для хранения констант в 1С

Краткий ответ

Одна таблица — Константы. Все константы конфигурации хранятся в единой таблице базы данных, независимо от того, сколько констант определено в конфигурации.

Архитектура хранения констант

В физической БД это выглядит так:

-- PostgreSQL / MSSQL / MySQL
Таблица: Константы (или Constants)
┌──────────────────┬──────────────────┬──────────────────┐
│ _Key             │ _Value           │ _Marked          │
├──────────────────┼──────────────────┼──────────────────┤
│ uuid1 (НалогLaw) │ "2023-01-15"     │ FALSE            │
│ uuid2 (МинСумма) │ 100.00           │ FALSE            │
│ uuid3 (НДСставка)│ 0.18             │ FALSE            │
│ uuid4 (НазваниеФ)│ "ООО Альфа"      │ FALSE            │
└──────────────────┴──────────────────┴──────────────────┘

Ключевые колонки:

• _Key — внутренний UUID или идентификатор константы
• _Value — значение (хранится в виде строки и конвертируется при загрузке)
• _Marked — флаг удаления (мягкое удаление)

Почему одна таблица, а не много

Причина 1: Производительность

Если бы каждая константа лежала в отдельной таблице:

Таблица: ПроцентыНалогов
  ├─ НДС
  ├─ НДСУСН
  └─ АвансовыйНалог

Таблица: ПараметрыСистемы
  ├─ МинимальнаяСумма
  ├─ МаксимальнаяСумма
  └─ ДефолтнаяВалюта

// Это привело бы к МНОЖЕСТВУ таблиц
// Каждый JOIN был бы дороже
// Индексирование усложнилось

Причина 2: Семантика

Константы — это единственные в системе объекты, которые:

• Не имеют иерархии
• Не имеют версионирования
• Не имеют истории изменений
• Не имеют пользовательских реквизитов
• Хранят только одно значение

Для такой простой сущности логично иметь одну таблицу.

Как константа определяется в конфигурации

// В конфигураторе вы определяете константу так:

Константа "НДСРазмер" Тип = Число(3,2)
Представление = "Размер НДС"
Помощь = "Налоговая ставка НДС в процентах"

// При компиляции платформа:
// 1. Создаёт запись в таблице Константы
// 2. Присваивает ей UUID
// 3. Создаёт в памяти объект типа Константа

Как это работает в коде

// Чтение константы
НДС = Константы.НДСРазмер.Получить();
// Под капотом платформа:
// 1. SELECT _Value FROM Константы WHERE _Key = 'uuid_НДС'
// 2. Конвертирует строку в число(3,2)
// 3. Возвращает значение

// Запись константы
Константы.НДСРазмер.Установить(0.20);
// Под капотом:
// 1. UPDATE Константы SET _Value = '0.20' WHERE _Key = 'uuid_НДС'
// 2. Инвалидирует кэш в памяти
// 3. Синхронизирует со всеми пользователями (если многопользовательская сессия)

Кэширование в памяти

Одна важная деталь: константы кэшируются в памяти приложения.

// Первый вызов
НДС1 = Константы.НДСРазмер.Получить();  // SELECT к БД

// Второй вызов в той же сессии
НДС2 = Константы.НДСРазмер.Получить();  // БЕЗ SELECT, из кэша

// Сложение: O(1) дважды, вместо O(n) SQL запросов

Это очень важно для производительности: если вы читаете одну и ту же константу 1000 раз в цикле, это не приведёт к 1000 SQL запросов.

Когда кэш инвалидируется

// Кэш перезагружается когда:

1. Константу обновил этот же сеанс
   Константы.НДС.Установить(0.25);  // запись в БД + инвалид кэша

2. Другой пользователь обновил константу
   // Платформа уведомляет этот сеанс через механизм обмена сообщениями
   // Кэш инвалидируется, следующий Получить() лезет в БД

3. Перезагрузка сеанса
   // Все кэши очищаются

4. Явное очищение кэша (редко)
   // Процедура с помощью сервиса обновления кэша

Особенности параллельного доступа

В многопользовательской базе константы требуют синхронизации:

// Сценарий гонки
Участник 1: НДС = 0.18, читает → кэш = 0.18
Участник 2: НДС = 0.20, обновляет → БД = 0.20
Участник 1: читает из кэша → 0.18 (устаревшая!)

// Платформа решает это так:
// Если константу обновил ЧТО-ТО в многопользовательской сессии,
// все остальные сеансы получают событие

Механизм доступа через объект

// Получение объекта константы
ОбъектКонстанты = Константы.НДСРазмер;

// Это возвращает объект типа ОбъектНастройки (ConstantValueObject)
Тип(ОбъектКонстанты); // ОбъектНастройки

// Методы:
// Получить() — читает значение
// Установить(Значение) — устанавливает и сохраняет

// Свойство:
ТекущееЗначение = ОбъектКонстанты.Значение;  // Текущее значение в памяти

Таблица в СУБД: структура

-- Реальная таблица в PostgreSQL (примерно)
CREATE TABLE Constants (
    _Key UUID PRIMARY KEY,
    _Value TEXT,
    _Marked BOOLEAN DEFAULT FALSE,
    _Changed TIMESTAMP DEFAULT NOW()
);

-- Индексы:
INDEX idx_key ON Constants(_Key);
-- Вот и всё. Никаких других индексов не нужно,
-- потому что ключ уникален и индексирован.

Сравнение с другими типами данных

Тип объекта         │ Таблица в СУБД  │ Количество записей
─────────────────────┼─────────────────┼─────────────────────
Константа           │ Константы       │ = количество констант
Справочник          │ Справочник_*    │ = записи справочника
Документ            │ Документ_*      │ = документы + движения
Регистр             │ Регистр_*       │ = записи регистра
Регистр сведений    │ РегистрСвед_*   │ = последние значения

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

// Типичное использование констант

Константы:
  ├─ НДСРазмер (число)
  ├─ СрокДоставки (число дней)
  ├─ НазваниеОрганизации (строка)
  ├─ ДефолтнаяВалюта (ссылка на справочник)
  ├─ РабочийГрафик (число часов в день)
  └─ ЛицензионныйКлюч (строка, зашифрованная)

// НЕПРАВИЛЬНОЕ использование констант:
// Переменные данные (которые часто меняются)
// → используй Регистр сведений вместо этого

// Если нужна история изменений
// → используй Документ, а не константу

Итог

Ответ: одна таблица Константы для всех констант конфигурации.

Почему:

• Константы хранят одно простое значение без версионирования
• Все константы имеют одинаковую структуру
• Производительность: индекс на UUID достаточен
• Кэширование в памяти скрывает работу с БД
• Однозначное семантическое определение: одна сущность — одна таблица

Аналогия: как в файловой системе все конфиги могут лежать в одной папке /etc/ вместо отдельной папки для каждого конфига.