В среде разработчиков 1С часто возникает вопрос: зачем тратить время на переименование таблиц в конструкторе запросов или вручную, если платформа и так подставляет стандартные имена? На первый взгляд может показаться, что Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары — это вполне информативно. Однако при работе со сложными алгоритмами избыточность или, наоборот, невнятность имен становится серьезным препятствием. Разберем детально, почему использование псевдонимов (алиасов) — это не просто прихоть, а стандарт профессиональной разработки.
Рассмотрим ситуации, в которых платформа 1С жестко требует переименования источников данных. Во-первых, это вложенные запросы. Если мы используем результат одного запроса внутри другого в секции ИЗ, язык запросов не сможет обратиться к этому виртуальному источнику, если мы не дадим ему имя. Проанализируем пример структуры:
ВЫБРАТЬ
ВложенныйИсточник.Номенклатура,
ВложенныйИсточник.Количество
ИЗ
(ВЫБРАТЬ
Продажи.Номенклатура КАК Номенклатура,
Продажи.Количество КАК Количество
ИЗ
РегистрНакопления.Продажи КАК Продажи) КАК ВложенныйИсточник
В данном случае ВложенныйИсточник — это обязательный псевдоним. Без него система выдаст синтаксическую ошибку.
Во-вторых, выясним причину необходимости алиасов при самосоединениях (Self-join). Представим ситуацию, когда нам нужно сравнить продажи одного и того же товара за два разных периода. Мы выбираем одну и ту же таблицу РегистрНакопления.Продажи дважды. Чтобы система понимала, из какого именно экземпляра таблицы брать поле СуммаОборот, мы обязаны назначить им разные имена, например, ПродажиТекущий и ПродажиПрошлый. Без этого обращение к полям станет неоднозначным, и запрос не будет выполнен.
Давайте разберем ситуацию с точки зрения поддержки кода другим программистом. В крупных конфигурациях, таких как 1С:ERP или 1С:УТ 11, существуют универсальные регистры, которые хранят данные разного смысла. Использование стандартного имени регистра часто дезориентирует. Проанализируем пример: если мы делаем выборку из регистра ЗаказыКлиентов, но фильтруем только те записи, по которым произошла просрочка отгрузки, логично переименовать таблицу в ПросроченныеЗаказы.
Это позволяет сразу понять суть данных в текущем контексте, а не просто источник их получения. Когда через полгода вы вернетесь к этому запросу, вам не придется заново изучать условия связи и фильтры, чтобы понять, что именно лежит в этой таблице.
Фирма «1С» устанавливает четкие правила для именования временных таблиц. Использование технических имен типа Т1, ТЧ или автоматических имен, которые предлагает конструктор (например, ВременнаяТаблица1), считается признаком низкой квалификации. Посмотрим на рекомендации:
ВТ_ или ВТ для всех временных таблиц. Это позволяет мгновенно отличить в коде обращение к физической таблице БД от обращения к данным, подготовленным в памяти. Например: ВТ_ОстаткиТоваров, ВТ_ЦеныДляРасчета.ВТ_ДанныеПоСотрудникам.Соблюдение этого правила критически важно при Code Review в профессиональных командах. Код с именами Т1, Т2 обычно отправляется на доработку без обсуждения.
Посмотрим на практическую сторону написания кода. Длинные имена объектов метаданных, такие как РегистрСведений.ЦеныНоменклатурыПоставщиков.СрезПоследних, при соединении нескольких таблиц превращают текст запроса в нечитаемое полотно. Если использовать такие имена в секции ГДЕ или в условиях связи ПО, код растягивается по горизонтали, заставляя разработчика постоянно использовать прокрутку.
Заменив это на короткий, но понятный алиас ЦеныПоставщиков, мы добьемся того, что вся логика соединения будет видна на одном экране. Это снижает риск допустить ошибку в условиях JOIN, так как структура запроса становится компактной и наглядной.
Рассмотрим более продвинутый аспект — отделение логики от структуры. Представим, что ваш запрос использует таблицу Документ.РеализацияТоваровУслуг.Товары. Вы везде в коде обращаетесь к ней по полному имени. Если через месяц логика изменится, и данные нужно будет брать не из документа, а из заранее подготовленной временной таблицы ВТ_ТоварыКОтгрузке, вам придется переписывать весь запрос, заменяя каждое упоминание старой таблицы.
Если же вы изначально использовали алиас ТоварыДляОбработки, вам достаточно изменить только одну строку в секции ИЗ:
// Было:
ИЗ Документ.РеализацияТоваровУслуг.Товары КАК ТоварыДляОбработки
// Стало:
ИЗ ВТ_ТоварыКОтгрузке КАК ТоварыДляОбработки
Весь остальной код запроса, использующий ТоварыДляОбработки.Номенклатура, ТоварыДляОбработки.Количество и так далее, останется неизменным. Это и есть принцип абстракции, который существенно облегчает рефакторинг и масштабирование системы.
Многие разработчики предпочитают писать запросы руками в текстовом редакторе. Использование осмысленных и лаконичных псевдонимов значительно ускоряет работу контекстной подсказки (IntelliSense). Набрать ВТ_Спецификации. и получить список полей гораздо быстрее, чем вводить полное техническое наименование объекта метаданных. К тому же, это снижает вероятность опечаток в именах таблиц при их многократном упоминании в сложных условиях.
Подведем итог: переименование таблиц — это инструмент управления сложностью. Если ваш запрос состоит из выбора трех полей одной таблицы, алиас может показаться лишним. Но как только появляются соединения, вложенные запросы или временные таблицы, использование понятных псевдонимов становится обязательным.
Рекомендуем придерживаться следующих правил:
ВТ.ТЧ_Товары вместо РеализацияТоваровУслугТовары).Т1, Т2, Табл, Выборка.Применяя эти подходы, вы сделаете свой код профессиональным, удобным для чтения и легким в поддержке, что в конечном итоге сэкономит время вам и вашим коллегам.