Ключ таблицы в 1С: что это такое и как работает

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

Понятие ключа встречается в 1С повсюду: уникальный идентификатор ссылочного объекта, измерения регистра сведений, номер и дата документа, поле «Код» справочника. Хотя разработчик редко создаёт ключи «вручную», как в классическом SQL, понимание их устройства необходимо для грамотного проектирования конфигурации и оптимизации запросов.

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

Что такое ключ таблицы простыми словами

В теории баз данных ключ — это минимальный набор атрибутов, значения которых не повторяются ни в одной строке таблицы. Если представить таблицу сотрудников, то комбинация «фамилия + табельный номер» может быть ключом, а просто «фамилия» — нет, потому что однофамильцы встречаются часто.

Различают первичный ключ, который однозначно идентифицирует запись и используется для ссылок на неё из других таблиц, и уникальные (альтернативные) ключи, которые тоже не допускают дублей, но не являются основным идентификатором. В 1С обе роли распределены между механизмами платформы.

Важно понимать: в 1С разработчик почти никогда не создаёт ключи напрямую SQL-операторами. Платформа сама формирует структуру физических таблиц на основе метаданных конфигурации — справочников, документов, регистров. Задача разработчика — правильно описать метаданные, а платформа превратит их в ключи и индексы.

Как устроены ключи у ссылочных объектов

Каждый объект ссылочного типа — справочник, документ, план счетов, план видов расчёта — получает при создании уникальный идентификатор (GUID). Это 16-байтовое значение, которое формируется платформой и никогда не повторяется в пределах всей базы.

Именно GUID служит первичным ключом физической таблицы. Когда в реквизите документа хранится ссылка на элемент справочника, фактически в поле записывается этот идентификатор. Получить его в коде можно методом УникальныйИдентификатор(), а обратно получить ссылку — через ПолучитьСсылку(Новый УникальныйИдентификатор(...)).

Помимо GUID, у ссылочных объектов есть дополнительные ключевые поля. У справочника это «Код» — по умолчанию платформа контролирует его уникальность, если в конфигураторе включён соответствующий признак. У документа логическим ключом выступает комбинация «номер + дата + вид документа», хотя физически первичным ключом остаётся GUID.

Ключи в регистрах сведений и накопления

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

Если регистр сведений подчинён регистратору, в ключ дополнительно входит ссылка на документ-регистратор и номер строки движения. То же справедливо для регистров накопления: уникальность записи обеспечивается связкой «регистратор + номер строки», а измерения в ключ не входят и могут повторяться сколько угодно.

Это принципиальная разница, которую часто упускают. В независимом регистре сведений «Цены номенклатуры» с измерением «Номенклатура» нельзя хранить две цены на один товар в один период — вторая запись просто заменит первую или вызовет ошибку в зависимости от режима записи. В регистре накопления «Продажи» одинаковые измерения в разных строках документа — нормальная ситуация.

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

Независимый регистр сведений

Ключ — измерения плюс период. Подходит для данных без документа-источника; дубли по измерениям невозможны

Регистр, подчинённый регистратору

Ключ — регистратор и номер строки. Подходит для движений документов; измерения могут повторяться

Справочник или документ

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

Индексы и их связь с ключами

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

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

Злоупотреблять индексами не стоит. Каждый индекс замедляет запись данных, потому что СУБД приходится обновлять не только таблицу, но и все её индексы. Разумный подход — индексировать только те поля, которые реально участвуют в отборах отчётов и запросов.

Типичные ошибки при работе с ключами

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

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

Третья ошибка — ручное вмешательство в физические таблицы средствами SQL: изменение GUID, удаление записей напрямую, отключение ограничений уникальности. Такие действия нарушают ссылочную целостность, и платформа начинает выдавать «битые ссылки» — объекты, ссылающиеся на несуществующие записи.

Как проверить и исправить проблемы с ключами

Для диагностики используйте штатные средства. Проверить уникальность кодов справочника можно запросом с группировкой по коду и подсчётом количества ссылок — значения больше единицы укажут на дубли. Для регистров сведений аналогично группируйте по всем измерениям и периоду.

Битые ссылки ищутся запросом с левым соединением: если ссылка в реквизите не находит соответствия в таблице справочника, значит, объект был удалён физически. В пользовательском режиме такие записи отображаются как «Объект не найден».

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

После исправлений полезно выполнить реструктуризацию и реиндексацию таблиц. В файловом варианте это делается через «Тестирование и исправление» в конфигураторе, в клиент-серверном — штатными средствами СУБД под контролем администратора.

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

Частые вопросы о ключах таблиц в 1С

Можно ли изменить GUID существующего объекта?

Штатными средствами — нет, идентификатор назначается при создании объекта и остаётся постоянным. Технически GUID можно задать при создании новой ссылки через метод УстановитьСсылкуНового, но подмена идентификатора у существующего объекта сломает все ссылки на него.

Почему в регистре сведений не сохраняется вторая запись?

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

Чем ключ отличается от индекса?

Ключ гарантирует уникальность записей и используется для ссылок, индекс лишь ускоряет поиск. Первичный ключ всегда проиндексирован автоматически, но не каждый индекс является ключом — обычный индекс допускает повторяющиеся значения.

Нужно ли индексировать код справочника?

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

Что делать, если после обмена появились дубли элементов?

Причина обычно в том, что объекты созданы независимо в двух базах и имеют разные GUID при одинаковом смысле. Используйте обработку поиска и замены дублей, а в настройках обмена настройте поиск по ключевым полям, чтобы платформа сопоставляла объекты до создания новых.

Безопасно ли чистить регистры напрямую в SQL?

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