В процессе разработки на платформе 1С:Предприятие часто возникает дилемма: использовать специализированный тип УникальныйИдентификатор или обычную строку. Особенно остро этот вопрос встает, когда необходимо реализовать нетипичный функционал, например, частичный поиск по идентификатору. В данной статье мы подробно разберем, как эти типы данных хранятся «под капотом» СУБД, как они индексируются и какой вариант будет наиболее оптимальным для производительности вашей системы.
Для того чтобы принять взвешенное решение, проанализируем, как 1С преобразует свои типы данных в типы SQL-сервера. Разберем ключевые различия в объемах хранения:
binary(16). Это фиксированный массив из 16 байт. Это максимально компактный формат для хранения 128-битного числа, которым по сути и является GUID.NVARCHAR(36).Посмотрим на цифры. В кодировке UTF-16, которую использует 1С, каждый символ занимает 2 байта. Таким образом, строка из 36 символов займет 72 байта. Добавим к этому еще 2 байта, которые SQL Server тратит на хранение фактической длины строки для типа NVARCHAR. Итого — 74 байта против 16 байт у идентификатора. Разница в объеме хранения составляет более чем 4.5 раза.
Проанализируем ситуацию с индексами. Любое измерение регистра сведений, по которому ведется поиск, включается в индекс. Если ваша таблица содержит миллионы записей, использование строк вместо УникальныйИдентификатор приведет к лавинообразному росту размера индексных файлов. Это, в свою очередь, увеличит нагрузку на дисковую подсистему и оперативную память сервера (RAM), так как кэшировать тяжелые индексы становится сложнее.
Важно понимать, что 1С не просто передает GUID операционной системе, она применяет специфическую оптимизацию. Выясним, почему это критично для производительности:
Стандартные GUID (версии 1), генерируемые Windows, содержат временную метку. Однако части этой метки расположены так, что последовательно созданные идентификаторы сильно различаются в своих начальных байтах. Если записывать их в СУБД «как есть», индекс станет сильно фрагментированным. При каждой вставке новой записи серверу придется перестраивать дерево индекса в разных местах, что катастрофически замедляет запись (INSERT).
Механизм «инвертирования» в 1С: Платформа 1С при записи в базу данных «переворачивает» байты времени в GUID, перемещая наиболее часто меняющиеся части в конец, а стабильные (связанные с временем) — в начало. Благодаря этому новые ссылки в 1С ложатся в индекс почти последовательно. Рассмотрим этот момент подробнее: если вы замените УникальныйИдентификатор на произвольную строку, вы потеряете эту внутреннюю оптимизацию. Ваша база данных начнет страдать от высокой фрагментации индексов при интенсивной записи.
Рассмотрим основной вопрос автора темы: «Я хочу найти записи, которые содержат последовательность из 5 символов внутри идентификатора». Кажется, что смена типа на строку решит проблему, но так ли это с точки зрения SQL?
В реляционных базах данных поиск по условию LIKE '%12345%' (с процентом в начале) является неселективным. Это означает, что SQL Server не может использовать индекс для поиска. Ему придется выполнить полное сканирование таблицы или индекса (Index Scan), перебирая каждую запись. Таким образом, даже если вы перейдете на строковый тип, скорость поиска по «середине» строки на больших объемах данных останется крайне низкой.
Для эффективного решения задачи поиска по подстроке в 1С рекомендуется использовать Полнотекстовый поиск (ППД). Разберем алгоритм правильной реализации:
УникальныйИдентификатор для связи и обеспечения уникальности (сохраняем компактность БД).Посмотрим на пример того, как правильно преобразовать GUID в строку и обратно, сохраняя правильный формат. Помним, что в 1С строковое представление GUID включает дефисы и имеет длину 36 символов.
// Пример получения строкового представления для записи в индексный реквизит
УидОбъекта = Новый УникальныйИдентификатор();
СтрокаДляПоиска = Строка(УидОбъекта); // Получим формат "ec9b1edd-9c20-4285-94b9-8c69c4a34f6e"
// Если нам нужно очистить строку от дефисов для экономии места (до 32 символов)
ЧистаяСтрока = СтрЗаменить(СтрокаДляПоиска, "-", "");
Проанализируем обратную ситуацию. Если вы решите хранить данные в строке длиной 32 символа (без дефисов), вам придется вручную восстанавливать формат GUID при необходимости преобразования типа. Рассмотрим, как это сделать:
// Восстановление GUID из строки 32 символа
Функция ВосстановитьУИД(Стр32)
Шаблон = "$1-$2-$3-$4-$5";
// Используем регулярное выражение или СтрШаблон для расстановки дефисов
// Формат UUID: 8-4-4-4-12 символов
Часть1 = Лев(Стр32, 8);
Часть2 = Сред(Стр32, 9, 4);
Часть3 = Сред(Стр32, 13, 4);
Часть4 = Сред(Стр32, 17, 4);
Часть5 = Прав(Стр32, 12);
Стр36 = СтрШаблон("%1-%2-%3-%4-%5", Часть1, Часть2, Часть3, Часть4, Часть5);
Возврат Новый УникальныйИдентификатор(Стр36);
КонецФункции
Подведем итог нашему исследованию. Использование типа УникальныйИдентификатор — это не просто следование стандартам 1С, но и залог высокой производительности на уровне СУБД.
Основные выводы:
УникальныйИдентификатор в 4.6 раза компактнее строки NVARCHAR(36). Это критично для размера индексов и скорости работы с оперативной памятью.LIKE одинаково медленен и для binary (с приведением типов), и для nvarchar.Если ваша задача требует частого поиска «кусков» идентификатора, наиболее профессиональным подходом будет создание **дополнительного строкового реквизита** (не измерения!) и индексация его средствами полнотекстового поиска. Это позволит вам сохранить «легкую» структуру регистра и при этом обеспечить пользователям мгновенный поиск по любым символам.
Также стоит помнить о регистре символов. При сравнении строк "A1" и "a1" результат зависит от настроек Collation базы данных (обычно в 1С они нечувствительны к регистру, но это не гарантировано). Тип УникальныйИдентификатор всегда обрабатывает символы A-F идентично, независимо от регистра, что исключает ошибки при обмене данными между разными системами.