Областьданныхосновныеданные 1с для чего

Обновлено: 04.07.2024

Использование общих реквизитов без разделения данных

Общие реквизиты - это объекты метаданных, позволяющие добавить реквизит сразу для множества прикладных объектов (справочников, документов, регистров).

Общие реквизиты можно разделить на два типа: используемые для разделения данных и не используемые для разделения данных. Это регулируется свойством «Разделение данных».

Назначение общих реквизитов, используемых для разделения данных, вполне очевидно. Они позволяют включить в конфигурации механизм разделения данных (multitenancy), обеспечивающий работу в одной информационной базе нескольких логически независимых или слабо зависимых областей данных.

Для чего предназначены общие реквизиты без разделения данных?

Прежде всего нужно обратить внимание на то, что не только сами общие реквизиты создаются в метаданных отдельно от прикладных объектов, в которых они используются (справочников, документов, регистров, и т.д.), но и описание включения общих реквизитов в прикладные объекты выполняется в самих общих реквизитах. Для этого используется свойство общего реквизита Состав , в котором указывается, в какие прикладные объекты включать общий реквизит. Кроме того, имеется возможность автоматического включения общего реквизита в прикладные объекты (свойство общего реквизита - Автоиспользование ). Это позволяет включать общий реквизит во все новые объекты метаданных без каких-либо действий со стороны разработчика конфигурации.

Таким образом, общие реквизиты, по сути, являются данными, добавляемыми к прикладным объектам со стороны конфигурации, а не со стороны разработки конкретного объекта. Это особенно ярко проявляется, если рассматривать жизненный цикл разработки (обновление конфигурации, доработку конфигурации при внедрении, перенос функционала между конфигурациями, и т.д.).

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

Например, может стоять задача реализации механизма создания сокращенной резервной копии данных, с наиболее критичными данными. Допустим, уже имеется некоторая конфигурация и, разумеется, желательно минимизировать изменения в самой бизнес-логике прикладных объектов конфигурации. Для решения задачи можно создать общий реквизит " ВключатьВРезервнуюКопию " и включить в его состав большинство прикладных объектов. Далее можно реализовать регламентное задание или обработку с пользовательским интерфейсом, которые будут по некоторым правилам проставлять этот признак. Например, признак может быть проставлен документам, введенным за последние 12 месяцев. Соответственно реализуемый механизм выгрузки будет использовать этот реквизит для отбора выгружаемых значений. Разумеется, данную задачу можно решить и другими способами. Здесь она приведена для иллюстрации тех случаев, в которых имеет смысл применять общие реквизиты без разделения данных.

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

Предисловие

Начиная с версии платформы 8.2.14.x и до последних актуальных релизов, в дереве метаданных конфигурации имеется такой объект как "Общие реквизиты". Подобный функционал предоставляла еще платформа 7.7, но в восьмой ветке эти возможности стали доступны далеко не сразу.

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

Возможности

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

Рассмотрим пример. В некоторой тестовой конфигурации, которой на самом деле не существует :), создадим четыре документа с именами "Doc1", "Doc2", "Doc3" и "Doc4". В каждый из документов нам необходимо добавить комментарий, причем он должен отображаться в форме списка каждого из документов.

Для этого создадим новый объект конфигурации в ветке "Общие -> Общие реквизиты" и назовем его "Комментарий". Тип значения укажем "Строка" длинной 255 символов. Также включим многострочный режим. Результат описанных действий Вы можете видеть на скриншоте "Настройки общего реквизита" ниже.

Все настройки аналогичны настройкам любого реквизита документа, за исключением раздела "Использование". Здесь нас интересует опция "Состав", в которой определяется состав объектов конфигурации. Именно здесь и будет определяться список тех объектов, для которых будет использоваться этот общий реквизит. Включим использование для первых трех документов.

Отметим, что режим использования "Автоматически" ориентируется на настройку "Автоиспользование" общего реквизита. В нашем примере свойство "Автоиспользование" для реквизита установлено в "Не использовать". Значит для документа "Doc4" общий реквизит не будет задействован, пока не включить использование явно.

В режиме конфигуратора сделаны все необходимые настройки. Запустим режим предприятия и откроем форму списка "Doc1". Мы увидим, что реквизит доступен как в списке, так и в форме документа.

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

Для общих реквизитов доступны стандартные возможности отбора, а в режиме конфигуратора работа с ними в форме документа никак не отличается от работы с обычными реквизитами.

Например, если создать запрос к документу "Doc3", то в доступных полях будет общий реквизит "Комментарий".

Единственное, чем функционал общего реквизита отличается от обычного, так это отсутствием возможности добавить его в графу журнала документов. В остальном же с ними можно работать стандартным образом.

Что там внутри

Для ответа на этот вопрос проанализируем как платформа 1С работает с общими реквизитами на стороне базы данных, а также каким образом к ним строятся запросы на выборку данных.

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

Обратимся к документу "Doc4", который не был включен в общий реквизит "Комментарий". Чтобы показать, как изменяется таблица документа в SQL-базе при добавлении его в состав общего реквизита, обратимся к следующему скриншоту.

Был добавлен общий реквизит с типом "Булево", в состав которого мы включили документ "Doc4". В итоге, при обновлении структуры информационной базы, в исходную таблицу "_Document10" было добавлено поле "_Fld17" булевого типа. Отсюда следует, что общие реквизиты добавляют к таблицам БД как дополнительные поля, аналогично тому, если бы мы создали вручную реквизиты для каждого документа.

Соответственно, запросы к таблицам SQL-базы будут в точности повторять запросы к полям, если бы они были созданы обычным способом. Делаем вывод, что явное отрицательное влияние на производительность отсутствует.

Но все ли так

Как обычно, не все так идеально. У общих реквизитов есть один существенный минус, как и у любого универсального подхода - это отсутствие возможности гибкой настройки этого реквизита для отдельных таблиц. На то он и общий, не так ли?

Например, в той же конфигурации, включив индексирование для общего реквизита "Комментарий", этот индекс будет создан в таблице каждого документа. Даже если индекс для конкретного документа будет не нужен, то отключить его средствами платформы 1С не будет возможности. Вот так индекс был добавлен в 3 документа, в которые мы добавляли общий реквизит "Комментарий".

Платформа 1С добавила индексы по общему реквизиту во все таблицы, которые входят в его состав.

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

Зачем отключать этот индекс? Обычно индексы добавляются для конкретных ситуаций. Добавляя их заранее для всех объектов, скорее всего некоторые из них будут избыточными (не всегда конечно же). С использованием общего реквизита Вы просто не сможете отключать индекс там, где он не используется.

Если сильно захотеть, то индекс удалить все же можно, воспользовавшись этим подходом, ведь где индекс можно добавить своими скриптами, такими же скриптами его можно и удалить. Там же в статье описаны все плюсы и минусы такого способа.

Кроме настройки индексирования Вы также лишаетесь возможности делать другие точечные настройки общего реквизита для объектов:

Использование в полнотекстовом поиске
Историю данных
Заполнение из данных заполнения
Проверку заполнения
И др.

Таким образом, использование общего реквизита обосновано, если все перечисленные проблемы не относятся к поставленной задаче разработки.

А как обстоят дела с использованием этого механизма в типовых конфигурациях?

В типовых конфигурациях

В типовых решениях Вы не часто встретите использование общих реквизитов, за одним большим исключением - это разделение данных из подсистемы "Работа в модели сервиса" из БСП. Подсистема позволяет разделить все хранимые данные в базе на изолированные части, чтобы в одной базе данных могли работать несколько компаний. Все это было сделано для облачной работы решений на платформе 1С.

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

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

Разделение данных можно найти во всех популярных решениях. На стороне базы данных они также отражены дополнительным полем, но за важным отличием - это поле добавляется во все индексы объекта с разделением на первую позицию. Не важно, используйте Вы разделение данных или нет - разделитель у Вас есть в базе и платформа использует его для построения запросов. В 100% случаев это числовое поле. Если разделение данных не включено, то оно заполняется значением "0" и по этому же значению устанавливается фильтр во всех запросах.

Есть интересный момент в анализе планов запросов при наличии разделителя в индекса. Как известно, операция "Table scan" или "Index scan" (сканирование, просмотр таблицы / индекса) обычно не очень хороший признак выполняемых запросов на больших таблицах. Взгляните на такой случай.

Уже из текста можно понять, что запрос скорее всего написан с ошибкой, т.к. выбирать всю таблицу реализаций - это последнее дело на больших базах. Если в базе разделителей нет (например, если у Вас старая и добрая УТ 10.3), то план запроса будет с операцией сканирования индекса.

Запрос платформой 1С будет сгенерирован примерно такой:

Логическая операция: Table scan
Количество прочитанных строк: 6076 (всего в таблице 6076, то есть она была прочитана полностью)
Очень неоптимально. Но какой запрос - такой и план.

Теперь выполним примерно такой же запрос на "Бухгалтерии предприятия 3.0", где разделитель данных уже присутствует. И вот результат.

SQL-запрос уже получил дополнительный фильтр по разделителю.

План тоже претерпел изменения.

От предыдущего примера план отличается тем, что операция теперь "Index Seek", вместо "Table Scan". Хотя прочитанных строк и затраченных ресурсов на выполнение запроса практически не изменилось.

Что все это значит? А то, что не нужно смотреть в плане запроса на выполняемые операции и ожидать, что если выполняется "Index Seek" (Поиск в индексе), то значит с запросом все хорошо. Поиск в индексе бывает разный, и не всегда оптимальный. Рекомендую отличную статью по работе с планами запросов "Планы запросов - это просто!" от Андрея Овсянкина.

Еще одним моментом, связанным с разделением данных, является падение производительности для тех пользователей, которые могут работать со всеми областями данных. В этом случае платформа 1С не ставит явный отбор по разделителю и практически все запросы превращаются в сканирование таблиц и индексов. Подробнее об этом Вы можете прочитать в статье "Управление доступом: роли, права, профили, группы доступа, функциональные опции, RLS" от Евгении Карук.

А Вы использовали когда-либо разделение данных? Есть чем дополнить материал?

Жизнь обычного разработчика

В самом начале статьи Вы видели пример добавления общего реквизита, но он не имеет ничего общего с практическими задачами. За весь опыт работы с платформой и различными конфигурациями мне известны лишь несколько кейсов, когда разработчики их применяли:

Добавление реквизита для объекта в типовой конфигурации, чтобы не затрагивать основной объект. Вроде как сделано, чтобы обновлять конфигурацию было проще.
Создание общих атрибутов для объектов в виде общих реквизитов (даты создания и изменения, ответственный и другие произвольные атрибуты).
Просто бездумное добавление полей, чтобы меньше "кликать" в конфигурации.

В отраслевых решениях можно встретить различного рода общие реквизиты, в отличии от решений фирмы "1С".

Использовать?

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

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

Механизм разделения данных позволяет хранить данные нескольких независимых организаций в одной информационной базе.

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

Допустим в конфигурации существует общий реквизит «Организация». Это значит (упрощённо), что у каждого справочника, документа или другого объекта конфигурации также будет существовать реквизит «Организация».

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

Теперь укажем, что общий реквизит «Организация» будет являться разделителем.

Тогда (упрощённо) в информационной базе будет создано несколько независимых областей данных, в каждой из которых будут храниться данные только для одной конкретной организации:

Теперь, заходя в программу, пользователь будет получать доступ не ко всей информации, которая есть в информационной базе, а только к данным «своей» области, в данном случае к документам, справочникам и др. своей организации.

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

В этом случае пользователь имеет доступ к «своей» области данных и к области неразделённых данных, которая является общей для всех пользователей.

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

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

Хватит это терпеть!

При работе с 1С, обновлять приходится многое: конфигурацию, КЛАДР, списки банков (лишают их лицензий, знаете ли), курсы валют (ох уж эти экономически нестабильные евро и доллары), списки пользователей, обработки, версию платформы. На хорошем железе обновление КЛАДРа со всеми регионами для одной базы занимает около получаса. Обновление конфигурации занимает от 10 минут до нескольких часов (при накатывании пачкой).

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

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

Базовая сегрегация

Для начала, нужно определить признак, по которому вы будете разделять базу. Разделитель может иметь любой тип данных, мы используем строку длинной 10 символов: ИНН организации. Главное — название разделителя (общего реквизита) не должно совпадать с уже существующими объектами конфигурации, то есть его нельзя назвать, например, «Организации», так как уже есть такой справочник. Мы назвали разделитель «Группа компаний».

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

Конфигуратор предложит создать параметры сеанса — безмолвно соглашаемся и идём дальше. После создания «Общего реквизита» с включённым свойством разделения, база данных становится похожа на многоэтажный дом. В доме есть элементы доступные всем и с каждого этажа: лифт, лестничный пролёт, коммуникации, а есть уникальное, доступное только в пределах этажа: квартиры, коридор, окна. Метафора простая, и, надеюсь, понятная:)

Для входа в определённую организацию (или область базы) необходимо сообщить разделитель в строке подключения к базе или указать его в v8i файле (о которых мы рассказывали в прошлый раз).

После /Z указываем общие реквизиты по порядку. Так как в нашей типовой бухгалтерии уже есть два общих системных реквизита, указываем для них значение -0 чтобы они не использовались, а в качестве третьего (который мы создали) передаём ИНН.

1000 и 1 чекбокс

Теперь нужно определить, какая часть данных будет являться общей для всех областей. Всё это настраивается через конфигуратор. В свойствах общего реквизита, который мы только что создали, есть пункт «Состав» открывающий небольшой список из 800 параметров:

Подбор параметров оставляем на ваше благоразумие, усмотрение и окружение. Вот наш вариант (аккуратнее, там 20 000 пикселей).

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

Выгружаем данные из текущих баз

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

Хозяйке на заметку: справочники и документы лучше выгружать отдельно — так можно избежать лишних ошибок в момент загрузки.

Загружаем данные в разделённую базу

Запускаем 1С с параметром /Z «-0,-0,+%ваш разделитель%», указывая разделитель той организации, данные которой собираемся загрузить. Запускаем универсальный обмен и скармливаем ему полученные при выгрузке файлы: сперва справочники, потом документы. Повторяем эту операцию для каждой .

Чтобы упростить задачу, мы осуществляем выгрузки массово, предварительно запуская чуть исправленную стандартную обработку через командную строку (/Execute c:\выгрузка.epf). Затем вручную загружаем полученные файлы в разделённую базу.

Как потратить больше времени, чтобы потратить меньше времени

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

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

Побочные эффекты: экономия места 1 к 20, косвенное увеличение скорости работы — неоценимо. В абсолютных цифрах: 50 организаций занимают 2 Гб пространства в SQL, тогда как одна отдельная база занимает от 800 Мб.

Читайте также: