Приветствую, друзья-разработчики, и те, кто только начинает свой путь в волшебном мире 1С! Сегодня мы поговорим о штуке, которая называется «регистры сведений 1С». Это универсальный инструмент, который помогает нам хранить и обрабатывать самую разную информацию.
Что такое регистры сведений?
Официальное определение звучит так: «Регистры сведений – это прикладные объекты конфигурации. Они позволяют хранить в прикладном решении произвольные данные в разрезе нескольких измерений. Например, в регистре сведений можно хранить курсы валют в разрезе валют, или цены предприятия в разрезе номенклатуры и типа цен».
Представьте, что у вас есть стеллаж, и вы можете раскладывать разные вещи по полочкам – разным ячейкам. Эти «полочки» и есть регистр сведений.
Когда использовать регистры сведений?
Использовать регистры сведений стоит, когда:
- Нам нужно хранить произвольные данные в различных разрезах. Это как конструктор LEGO, из разных «кубиков» можно собирать разные «модели».
- Данные необходимо периодически менять во времени (например, курсы валют, которые скачут, как зайцы, и их необходимо постоянно отслеживать).
- Нужно «привязать» данные к документу, который их меняет. Например, чтобы знать, кто именно изменил цену на условное «молоко».
- Нужна «история» изменения данных. Чтобы знать, когда «молоко» стоило 30 рублей, а когда стало 50. Вот это сказочные цены, да? Ха-ха.
А вот когда регистры лучше не использовать:
- Когда нам нужны справочные данные (то есть что-то, что не меняется часто и не является измерением другого объекта). Для этого есть справочники. Это как телефонная книга – информация есть, но меняется редко.
- Когда необходимо вести учет в разрезе каких-то объектов (например, остатков товаров или расчетов с контрагентами). Для этого в 1С у нас есть регистры накопления. Это как бухгалтерская книга – все строго, по порядку и с остатками.
Теперь поговорим о том, как правильно построить эти самые регистры, чтобы они работали быстро и не вызывали у нас головной боли.
«Размеры имеют значение» (или как правильно построить дом):
Представьте, что мы строим дом: чем крепче фундамент, тем дольше простоит здание. И если построить его по кривым чертежам, то получится Пизанская башня, а не добротный дом.
Начинаем, конечно же, с фундамента! Основа в нашем случае — это структура регистра.
Структура регистров сведений
Вся информация в регистре сведений хранится в виде записей. Каждая запись содержит значения измерений и соответствующие им значения ресурсов.
Измерения регистра описывают разрезы, в которых хранится информация. Измерения – это как «полочки» в нашем шкафу, по которым мы раскладываем информацию. Например, «Номенклатура», «Валюта», «Дата», «Организация». Чем больше «полочек», тем сложнее будет хранение. А вот ресурсы регистра содержат саму хранимую информацию. Это то, что именно мы храним в этих «полочках». Например, «Цена», «Курс», «Кратность».
Есть еще реквизиты регистра сведений. Это дополнительная информация, ее можно хранить вместе с каждой записью, находящейся в регистре сведений. Это как дополнительные «пометки» к нашим записям. Например, «Комментарий», «Ответственный», «Дата начала действия».
Какие измерения мы выберем, в каком порядке их поставим, какие ресурсы и реквизиты нам нужны. Тут как с планировкой квартиры: если все продумать, то жить будет комфортно, если нет — то спотыкаться о мебель всю жизнь. Или, как если бы вы построили коровник, а потом поняли, что там будут жить бегемоты.
Главное правило — все должно быть по делу. Не надо «лепить» лишние измерения, просто чтобы они были. Это как загромождать квартиру ненужными вещами. Чем больше всего навалим, тем сложнее будет что-то найти, и в итоге будете ходить по квартире, как по лабиринту.
Измерения, порядок и «волшебный» индекс (расставляем мебель):
И вот тут начинается самое интересное. Порядок измерений в регистре - это не просто «как захотелось», это очень важная вещь! Это как расставить мебель в комнате: если диван стоит там, где проход, то будет неудобно, и каждый раз вы будете спотыкаться, а в итоге возненавидите и диван, и планировку. Так и с измерениями: от их порядка зависит, как быстро будут выполняться запросы к регистру.
В СУБД (системе управления базами данных) есть такая штука — индекс. Это как «оглавление» в книге: помогает быстро найти нужную страницу. И в регистрах обнаруживаются индексы, строящиеся на основе измерений. Поэтому, если мы хотим, чтобы наши запросы «летали», то нужно правильно расставить измерения в регистре. Это как правильно приготовить борщ: если все ингредиенты в нужной последовательности, то получится отменно, а если навалить все в кастрюлю сразу, то… сами понимаете.
Представьте, что у нас регистрируются цены. И мы часто ищем цены по номенклатуре и виду цены. Тогда логично будет сначала поставить измерение «Номенклатура», а потом «Вид цены». А если мы будем искать по виду цены, а затем по номенклатуре, то «индекс» будет работать медленнее. Это как если бы вы попытались искать книгу в библиотеке не по оглавлению, а просто бегая между стеллажей в поисках нужной полки.
Реквизиты и ресурсы: есть ли разница? (стены и окна дома):
По сути, на уровне СУБД разницы между реквизитами и ресурсами нет. Но по логике - они разные. Ресурсы - это то, что мы непосредственно храним в разрезе измерений. Реквизиты — это дополнительная информация, которая может нам пригодиться. Это как если бы в доме были основные помещения (ресурсы) и кладовка с балконом (реквизиты).
Индексировать реквизиты и ресурсы стоит с умом. Тут как с окнами в доме: если их слишком много, то будет холодно, а если слишком мало - то темно. Если мы часто ищем данные по реквизиту, то его стоит проиндексировать. А если нет, то зачем тратить ресурсы? Представьте, что вы заклеили все окна дома, потому что «а вдруг кто-то подсмотрит?», а в итоге сами остались без света.
Периодичность: прошлое, настоящее, будущее (время как жилец нашего дома):
Очень часто мы хотим знать не только «что сейчас», но и «что было раньше». Для этого мы используем периодичность в регистрах сведений. Это как «лента времени», на которой мы видим, как менялись наши данные. Как если бы мы снимали фильм про жизнь нашего дома: как он строился, какие перестановки мебели в нем были.
Можно выбрать, с какой точностью хранить данные во времени: «в пределах дня», «в пределах секунды» и т.д. Чем точнее, тем больше места будет занимать регистр. Тут как с записями в дневнике: можно писать каждый день, а можно раз в месяц. Записывать все-все-все, конечно, прикольно, но места в «дневнике» может и не хватить.
Подчинение регистратору: ответственность или кандалы (кто хозяин дома?):
Регистр сведений можно «привязать» к какому-то документу. Это означает, что записи в регистре будут делаться только при проведении этого документа. Это как если бы в доме был один «хозяин», который следит за порядком. Тут как в коммунальной квартире: если каждый сам себе «хозяин», то порядка не будет, а если будет один «старший по дому», то и жить будет спокойнее.
С одной стороны — это хорошо, потому что есть контроль и все изменения фиксируются. С другой стороны — это может быть неудобно, если мы хотим изменить данные в регистре «вручную».
Итак, мы обсудили, как правильно построить регистры, чтобы они работали быстро и без сбоев. Мы говорили о структуре, измерениях, индексах, периодичности и подчинении регистратору. Теперь у нас есть все необходимые инструменты, чтобы «построить» крепкий и надежный «дом» для наших данных. Обсудим, как «заселять» этот дом новыми данными, и не делать так, чтобы он обвалился под тяжестью новых жильцов.
Записи — приключения в СУБД
Итак, наш «дом» построен, фундамент заложен, мебель расставлена. Теперь пришло время «заселять» его новыми «жильцами» — записями. И тут, как и при заселении в новый дом, могут возникнуть свои сложности. В этой главе мы разберемся, как правильно «записать» данные в регистр, чтобы все прошло гладко, без «суеты» и «пробок» в нашей базе.
Режимы записи: «заметать следы» или «бережно хранить» (выбираем стратегию заселения):
В 1С есть несколько режимов записи в регистр сведений. Как говорится, на любой вкус и цвет. Это как выбирать метод переезда: можно все «выкинуть» и купить новое, а можно «бережно упаковать» и перевезти все старое.
Запись с замещением: Этот режим похож на «генеральную уборку». Мы сначала выкидываем все старые записи, которые нам «не нравятся», и потом записываем новые. Это хорошо, когда мы точно знаем, что нам не нужны старые данные. Как если бы вы въехали в квартиру после капитального ремонта и все старое вынесли на свалку.
Запись без замещения: Этот режим более «деликатный». Мы сначала проверяем, нет ли уже таких записей, и только потом записываем новые. Это хорошо, когда мы хотим сохранить старые данные и добавить новые. Как если бы вы привезли в новую квартиру свои вещи и уже не знаете, куда их девать. Но при таком режиме есть шанс нарваться на «двойников», и тут нужно быть аккуратнее.
Запись без проверок: А это вообще «экстрим»! Мы просто «наваливаем» новые записи в регистр и ни о чем не думаем. Это хорошо, когда мы точно уверены, что наши записи уникальны и «дублей» не будет. Это как если бы вы «заселяли» в дом 100 человек, не проверяя, не «заселится» ли кто-то случайно дважды.
Менеджер записи — наш помощник или «тормоз»?
Менеджер записи — это специальный инструмент, который позволяет нам записывать данные в регистр «поштучно». Это как если бы мы «заселяли» в дом не сразу всех жильцов, а по одному.
С одной стороны, это удобно, когда нужно изменить одну запись. С другой стороны, если нужно записать много записей, то менеджер будет работать медленнее, чем запись набора.
Запись без проверок - «быстро и опасно» (рискованный переезд):
Как мы уже говорили, запись без проверок — это как ехать на машине по встречке: быстро, но опасно. Если мы не уверены, что наши записи уникальны, то мы получим «ошибку» от самой СУБД. Это как если бы вы при заселении перепутали все квартиры и устроились в чужой. Поэтому, когда используете этот режим, нужно быть очень внимательными.
Проверка: «А вдруг запись уже есть?» (ищем «двойников»):
Когда мы записываем данные в регистр, платформа «смотрит», нет ли уже таких записей. И если есть «двойники», то либо выбрасываем их (при записи с замещением), либо ругаемся (при записи без замещения). Для этого используются SQL запросы, которые вызывают «шум» в СУБД.
И тут тоже есть свои хитрости. Чем больше «полочек» (измерений) в регистре, тем дольше платформа будет искать «двойников». Это как если бы вы пытались найти одну и ту же книгу в огромной библиотеке.
Итак, мы разобрались, как правильно «заселять» в наш регистр новые данные. Теперь поговорим о том, как из этой «кучи данных» достать именно то, что нам нужно.
«Магия» виртуальных таблиц
Вот мы и подошли к последней главе. Наш «дом» (регистр) построен, «жильцы» (записи) заселены. Но как же теперь во всем этом «беспорядке» найти именно то, что нам нужно? В этой главе мы раскроем секрет «магии» виртуальных таблиц и научимся получать из регистра нужные нам данные с помощью конструкции «Срез последних».
СрезПервых/СрезПоследних: «берем только самое важное» (ловкость рук и никаких мошенничеств):
Представьте себе, что у нас есть лента времени со всеми изменениями цен на молоко. Но нам, как правило, нужна только последняя цена на сегодня. Вот тут-то нам и пригодятся конструкции «СрезПервых» и «СрезПоследних». Это как достать из почтового ящика только последние письма, не читая весь спам.
СрезПоследних: Возвращает нам последнюю запись в регистре на заданную дату, а также по заданным измерениям. Это как если бы мы хотели узнать «последнюю» цену на «Молоко», на «сегодня».
СрезПервых: Возвращает нам первую запись в регистре на заданную дату и по заданным измерениям. Это как если бы мы хотели узнать «первую» цену на «Молоко», которая была в этот день.
Как правильно отфильтровать данные (ищем нужную полку):
Когда мы делаем срез, очень важно правильно указать отборы. Это как если бы вы искали книгу в библиотеке: нужно точно указать название книги, автора и, возможно, год издания. Если вы начнете искать книгу, просто назвав отдел, в котором она предположительно находится, то поиски затянутся надолго.
Самая частая ошибка — это когда отборы по измерениям указывают в условии «ГДЕ» общего запроса, а не в виртуальной таблице среза. Это как если бы вы сначала вынесли все книги из библиотеки в кучу, а потом начали в ней искать нужную. А нужно сначала выбрать нужный отдел, а потом уже искать в нем нужную полку.
Таблица итогов: «Стоит ли игра свеч?»
Для периодических регистров сведений в 1С есть возможность сохранять так называемые таблицы итогов. Это как «конспект» со всеми важными данными. Срез последних или срез первых берут данные из этих таблиц.
Но эти таблицы нуждаются в поддержке в актуальном состоянии. И это требует дополнительных ресурсов при записи данных. Как и любая оптимизация, этот процесс должен быть обоснован.
Периодичность «По позиции регистратора»: «не все то золото, что блестит»:
Иногда разработчики «грешат» тем, что устанавливают периодичность «По позиции регистратора». Это позволяет в одну и ту же секунду записывать разные записи с одинаковыми измерениями. В реальности же это может создать проблемы, так как запрос на срез превращается в сложный и медленный «монстр».
Используйте эту периодичность только в том случае, если этого требует бизнес-логика, а не просто «чтобы было». Это как если бы вы вместо обычного автомобиля купили гоночный болид, хотя вы просто ездите на работу.
Когда делаешь запрос к регистру, иногда чувствуешь себя «хакером» из фильма: пишешь какой-то код, ждешь и, если все сделал правильно, получаешь «результат». И тут главное — не «напортачить», чтобы вместо нужной цены не получить, например, список всех котировок акций за последние 10 лет.
Вот мы и подошли к концу нашего путешествия по регистрам сведений в 1С. Надеюсь, что теперь регистры не будут ощущаться для новичков чем-то загадочным и сложным, а станут вашим верным помощником в разработке. Удачи!
