Что такое значение реквизита в 1с
Понятие "тип реквизита" отличается от понятия "тип значения"
Конкретное значение не может быть составного типа. Одно конкретное значение может быть только одного типа данных.
Реквизит может быть как одного типа, так и составного типа. В последнем случае его тип описывается объектом "ОписаниеТипов", т.е. список возможных типов, значения которых могут храниться в этой колонке. Например, СправочникСсылка.М1, СправочникСсылка.М2, Строка, Число, ДокументСсылка.Д1.
В каждой строке (элементе, записи) содержится какое-то свое значение, но каждое из них - одного типа. Например, "СправочникСсылка.М1". Если же в ячейке колонки, имеющей составной тип, даже не выбран (не назначен) тип значения, то оно содержит значение "Неопределено" (это значение и одновременно тип). Если же тип выбран (кнопкой Т или установлен программно), то ячейка содержит пустое значение этого типа, например, пустую ссылку на элемент справочника (см. v8: Пустые ссылки), пустую строку "" или 0.
Чтобы реквизиту составного типа установить конкретный тип, достаточно присвоить ему пустое значение этого типа.
Вопрос:
Какие существуют особенности работы с составными типами данных.
Ответ
Этот вопрос имеет два стороны:
1) Сторона элемента формы.
Для элемента формы мы можем установить только ограничение на типы которые можно выбрать.
Т.е. с помощью кода:
Мы ограничиваем возможный типы только одним "СправочникСсылка.Контрагенты".
НО это не действует на значение которое хранится в источнике данных.
Поэтому если реквизит который связан с "ПолеВвода1" имеет "составной" тип, например Любая ссылка,
он будет неопределенного типа даже после "ЭлементыФормы.ПолеВвода1.ОграничениеТипа=Новый ОписаниеТипов(МассивТипов);"
2) Сторона источника данных.
Здесь ограничение на тип накладывается либо в конфигураторе, либо в момент создания этого элемента из языка.
Но если у реквизита установлен "составной" тип значение реквизита будет неопределенно до тех пор, пока ему не будет присвоено значение конкретного типа.
Присвоить конкретное значение можно либо из языка, либо выбрав это значение в форме.
Из выше описанного можно сделать вывод:
Если у реквизита установлен "Составной" тип данных, то даже при ограничении возможных типов у элемента формы до одного возможного, у пользователя будет запрошен тип который нужно будет присвоить реквизиту.
Если мы хотим оградить пользователя от лишних движений, т.е. выбора единственно возможного типа, нам нужно предварительно установить тип реквизита.
Сделать это можно следующим образом:
Добавление от ezh (особенности при работе с элементами в табличном поле):
1.
Вместо этого:
Тип значения — классификация значений (то есть данных) по их виду — строки, числа, даты и т.п. Тип значения — это одно из базовых понятий в любом языке программирования.
Преобразование типов — это конвертация значения (данных) из одного типа в другой, например из строки в число или наоборот. Более узкое понятие форматирование значения — это конвертация из любого типа в строку с преобразованием в такой вид, который будет удобен пользователю для чтения, в том числе и локализация.
Существуют языки с жесткой типизацией данных. Это значит, что при создании (определении) переменной программист указывает жестко какой тип данных она может хранить. То же с функциями, параметрами процедур и т.п. В метаданных 1С тип у реквизитов жестко указывается (правда есть составной тип — позволяющий указать несколько вариантов). Но в программном коде на языке 1С нет жесткой типизации, а это значит, что можно создать числовую переменную, потом приравнять ее к строке. Функция может в зависимости от параметров и условий возвращать число, или булево, или строку.
Как в языке 1С работать с типами данных и как производить преобразование типов 1С?
Значение 1С Неопределено
Неопределено – это значение 1С, которое обозначает, что значения нет. С помощью этого значения 1С можно «обнулять» переменные, в том числе для неявного вызова деструктора, например COM объектов.
Переменная1 = Новый COMОбъект("Excel.Application");
Переменная1 = Неопределено;
Аналогичное значение 1С NULL, которое может вернуть запрос, при попытке получить данные из базы данных, если таковые получить не удалось (точнее — значение в поле NULL означает, что поле в базе данных «не заполнено»).
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
Если Выборка.Поле1 = NULL Тогда
Продолжить;
КонецЕсли;
КонецЦикла;
Типы значений 1С
В качестве «переменных» возможно использовать:
- Переменные, созданные в тексте программы (описанными выше способами)
- Реквизиты объекта метаданных или формы (созданными в конфигураторе, с указанием точного типа 1С).
Реквизит может иметь составной тип 1С, то есть несколько возможных. Назначение значения 1С пользователем в этом случае может быть двухэтапное:
- Выбор типа значения 1С из доступных
- Выбор значения 1С.
По умолчанию такой реквизит имеет значение 1С Неопределено. Когда выбран тип 1С, но еще не выбрано значение 1С – пустое значение этого типа 1С (0 для числа, пустая ссылка для ссылочных типов 1С, см. ниже). И наконец потом – значение 1С. Из программы назначения значения производится напрямую, без промежуточного выбора типа 1С.
Определить тип значения 1С возможно несколькими способами:
//способ 1 – сравнение с известными типами 1С
Переменная1 = 12;
Если ТипЗнч(Переменная1) = Тип("Число") Тогда
//…
ИначеЕсли ТипЗнч(Переменная1) = Тип("СправочникСсылка.ИмяСправочника") Тогда
//…
КонецЕсли;
Преобразование типов 1С
Значение 1С простых типов 1С можно преобразовывать с помощью оператора — наименования типа 1С:
//в число
ЗнчЧисло = Число("22"); //при невозможности преобразовать типы 1С будет вызвана ошибка, поэтому лучше использовать обработчик ошибок (см. далее)
//в строку
ЗнчСтрока = Строка(22);
ЗнчСтрока = СокрЛП(22);
ЗнчСтрока = Формат(22, "ЧГ=0");
//в дату
ЗнчДата = Дата("20120101120000"); //01.01.2012 12:00:00
ЗнчДата = Дата(2012, 01, 01, 12, 0, 0);
ЗнчДата = Дата(2012, 01, 01);
Преобразование типов 1С — значений сложных типов 1С
Форматирование значений 1С
Для точного указания формата используется функция Формат(), с помощью которой возможно указать требуемое представление.
ЧислоСтрокой = Формат(2400, "Настройки")
В качестве строки «Настройки» нужно указать требуемый формат 1С. Такие настройки указываются в специальном закодированном виде. Рассмотрим наиболее часто используемые настройки:
Формат 1С даты и числа по правилам различных стран
Если Вам требуется вывести дату или число и не хочется заморачиваться со знанием как они должны быть представлены по правилам нужной страны, есть простейшая настройка, которая позволит Вам это сделать:
L = КраткоеНаименованиеНужнойСтраны
Пример вывода даты по правилам некоторых стран:
Формат( ТекущаяДата(), «L=ru»)
> 28.03.2012 14:21:32
Формат( ТекущаяДата(), «L=en»)
> 3/28/2012 2:21:24 PM
Формат( ТекущаяДата(), «L=fr»)
> 28/03/2012 14:22:08
Формат даты в языке 1С
Если настройки по умолчанию Вам недостаточно и хотелось бы самостоятельно указать порядок частей даты и символы их разделения, необходимо использовать настройку:
ДФ = "дмг чмс"
Соответственно «дмг» – это день, месяц и год, а «чмс» — это часы, минуты и секунды. Любую из этих частей возможно пропустить. Порядок следования – любой. Символы, указанные между частями будут использованы как символы разделения.
Символ части даты м. б. указан несколько раз подряд, от этого зависит вид этой части даты, например «д» или «дд» или «дддд».
Расшифровка частей даты:
- д – день
o маленькая «д»
o от 1 до 4 раз - М – месяц
o большая «М»
o от 1 до 4 раз - г – год
o маленькая «г»
o 1 или 2 или 4 раз - ч – часы
o маленькая «ч» — 12ти часовой формат
o большая «Ч» — 24х часовой формат
o 1 или 2 раза - м – минуты
o маленькая «м»
o 1 или 2 раза - с – секунды
o маленькая «с»
o 1 или 2 раза - вв – отображение AM/PM для 12ти часового формата
- к – квартал.
Пример вывода даты с указанием правил:
Формат числа в языке 1С
В отличие от форматирование даты, где все достаточно просто, для форматирования числа есть множество вариантов параметров. Здесь рассмотрены те, которые чаще применяются.
Первая «проблема» связана с группировкой по умолчанию цифр в числах по 3 и разделением групп пробелом, например:
СтрЧисло = Строка(22300500)
> 22 300 500
Это неудобно, когда число преобразовывается к строке не для красивого и понятного вывода пользователю, а для служебных нужд. На это можно повлиять с помощью параметра «ЧГ», например:
Параметр, который позволяет округлить число при выводе до нужного количества цифр после запятой «ЧДЦ»:
Формат(3.535353, "ЧДЦ=""2""")
> 3,54
Параметр, который позволяет указать символ-разделитель целой и дробной части «ЧРД»:
Формат(3.535353, "ЧРД="".""")
> 3.535353
Для некоторых случаев бывает полезно иметь возможность вместо числа «0» отображать что-то другое: пустую строку или «не заполнено». Это позволяет делать параметр «ЧН»:
Формат(0, "ЧН="" """)
>
Что такое реквизиты 1С?
Мы с Вами недавно обсуждали справочники 1С и документы 1С. Работа пользователя со справочниками и документами в 1С состоит из заполнения полей на форме.
Реквизиты 1С – это поля справочника и документа, которые отображаются на форме, чтобы пользователь их заполнил.
Рассмотрим подробно тему реквизитов в 1С.
Что такое Реквизиты 1С
Каждый справочник и документ 1С состоит из набора полей. Такие поля называются реквизиты 1С (для программиста 1С).
В конфигураторе, в дереве конфигурации 1С, раскройте любой справочник или документ и Вы увидите ветку Реквизиты. Это список реквизитов (полей) справочника.
Поглядите как те же реквизиты 1С выглядят на форме справочника 1С.
Каждый реквизит 1С имеет свойства, в которых указано какой вид значения хранится в реквизите (строка, число и т.п.) и как с ним будет работать пользователь.
Нажмите правой кнопкой на любой реквизит 1С и нажмите Свойства. В окне справа откроется список свойств выбранного реквизита.
Основные свойства реквизитов 1С:
- Имя – наименование реквизита 1С в языке 1С (внимание – в имени реквизитов не должно быть пробелов и знаков препинания)
- Синоним – наименование реквизита каким его увидит пользователь в режиме Предприятие
- Тип – указывает какие данные можно будет хранить в реквизите 1С, нажмите на кнопку «…», чтобы изменить тип; основные типы:
o Число — используется для цифр, а также для радиопереключателя
o Строка — может быть ограничена по длине, дело в том, что не везде возможно использование неограниченной длины
o Дата
o Булево — для того, чтобы на форме была галочка (значения Истина/Ложь или Да/Нет)
o СправочникСсылка или ДокументСсылка – выбор значения справочника или документа.
Вы можете поставить галочку Составной тип данных и тогда 1С позволит Вам выбрать несколько типов данных одновременно. В этом случае пользователю будет отображаться кнопка Т, при нажатии на которых он выберет какие данные он хотел бы ввести.
Стандартные реквизиты 1С
Как Вы заметили, на форме справочника есть реквизиты 1С, которые отсутствуют в списке в конфигураторе: группа, наименование, БИК.
В форме списка справочника тоже есть реквизиты 1С, которых нет в списке: пометка удаления.
Это – стандартные реквизиты 1С. Что это такое? У каждого объекта 1С есть набор реквизитов 1С по умолчанию. У справочников это, например – код и наименование. У документов это – дата и номер.
Стандартные реквизиты 1С можно посмотреть следующим образом:
Общие реквизиты 1С
Начиная с версии 1С 8.2.14 в 1С появился новый Объект 1С – Общие реквизиты 1С. С помощью него можно добавить реквизит (поле), который будет присутствовать сразу во множестве справочников и документов.
Свойства общего реквизита 1С:
- Автоиспользование – добавляет общий реквизит 1С сразу во все справочники и документы
- Состав – позволяет добавить общий реквизит 1С только в нужные справочники и документы (автоиспользование тогда в значение Не использовать).
Как добавить реквизит 1С
Нажмем правой кнопкой на ветку Реквизиты 1С нужного справочника и выберем Добавить.
Введем нужно Имя реквизита 1С, например «АдресОфиса» и синоним «Адрес офиса». Тип оставим по умолчанию Строка, но поставим галочку Неограниченная длина.
Добавим еще один реквизит 1С точно так же, только выберем тип Булево, назовем его «РаботаетПоВыходным».
Как вывести реквизит на форму 1С (толстый клиент 1С)
Раскроем ветку Формы того же справочника. Чтобы открыть форму — выберем форму элемента и нажмем на нее два раза мышкой.
Потяните мышкой за край формы и растяните ее (необязательный пункт).
В панели конфигуратора нажмите кнопку «Размещение данных». Также можно использовать меню Форма / Размещение данных.
Вы видите – наши реквизиты на форму не выведены. Установите на них галочку. А также галочки Вставить надписи и Разместить автоматически.
Как вывести реквизит на форму 1С (тонкий клиент 1С)
Раскроем ветку Формы того же справочника. Выберем форму элемента и нажмем на нее два раза мышкой.
На закладке Реквизиты раскройте строку Объект. Вы увидите список реквизитов, добавленных ранее в справочник.
Теперь просто перетяните из правого окна в левую нужный реквизит и он появится на форме.
Реквизиты формы 1С
В толстом клиенте у формы есть свои собственные реквизиты. Они находятся на закладке Реквизиты.
Эти реквизиты не сохраняются в базе данных, однако их можно использовать на форме для полей, которые нужны для работы с формой.
Например, Вы добавили на форму галочку. При ее нажатии на форме что-то происходит. Значение галочки для Вас неважно (записывать его не нужно) – она используется только для переключения формы при работе с ней. В этом случае в качестве данных Вы используете не реквизит справочника, а реквизит формы.
Периодические реквизиты 1С
В 1С версии 7.7 были периодические реквизиты. Их смысл таков: значение у реквизита разное в разные даты. Например, значение на 1 сентября – одно, а на 1 октября – другое. У одного и того же реквизита.
В 1С 8 периодических реквизитов нет. Это реализуется следующим образом:
-
Добавляем регистр сведений и делаете его периодическим. Период может быть – секунда, день, месяц, квартал, год.
Дополнительные реквизиты и сведения существуют давно. Задумка очень хорошая. Суть этих механизмов понятна всем. По этому поводу написано много. Что тут можно сказать нового? Однако бес, как всегда, в деталях. Как создавали реквизиты в объектах типовых конфигураций, так и продолжаем это делать. Почему это происходит? За всех сказать не могу. Могу рассуждать только на своем примере. Являясь убежденным практиком, одно могу сказать вполне определенно. Если что-то на практике недостаточно удобно, то останется оно главным образом в теории. Если не приложить немного усилий.
Мне приходится активно перемещаться между различными конфигурациями, занимаясь их поддержкой и развитием. Встречаются разные случаи, но есть и много общего. Дополнительные реквизиты и сведения, наряду с использованием расширений, являются мощным инструментом сохранения типовых конфигураций в виде, пригодном для частого обновления. Однако, на практике, почти всегда встречается одно и то же. Расширения часто либо не используются по причине "потом не разобраться", либо наблюдается другая крайность - на каждую задачу свое расширение. Это тема отдельной статьи. Сейчас говорим о дополнительных реквизитах и сведениях.
Буду говорить о себе, потому что только о себе можно сказать наверняка. Почему, зная об этом механизме, я продолжал создавать реквизиты в конфигурации? Скажу прямо. Потому, что такова реальность. К сожалению, производством качественного и структурированного кода удается заняться далеко не всегда. Основную часть времени занимаемся судорожным производством *овнокода за очень ограниченный промежуток времени.
Со стороны заказчика требования по сохранению конфигурации в явном виде поступают не часто. Временами в постоянном цейтноте возникает даже некое злорадное чувство. Типа - получи, что хотел.
Как в таких условиях сохранить чувство собственного достоинства, уважение к себе и не навредить? Для себя выход вижу только один. Эффективно использовать БСП и создавать свои библиотеки там, где БСП "недорабатывает".
Теперь, к делу. Много раз внимательно читал модули БСП, предназначенные для работы с дополнительными реквизитами и сведениями. Возможно, у меня плохо со зрением, но впечатление сложилось вполне определенное. Много корректного кода. Но реального набора функций, позволяющих программно работать со свойствами так же удобно, как с реквизитами объекта нет. ИМХО - прослеживается ориентация на интерактивные средства. Все направлено на то, чтобы наглядно представить наборы свойств на форме, создав иллюзию у пользователя, что он работает с обычными реквизитами.
Само по себе - это замечательно. Только, на мой взгляд, забыли о программистах, от которых собственно и зависит - будут ли активно использоваться свойства или нет. Возможно, предполагалось, что программисты способны позаботиться о себе сами. Ну, значит так тому и быть.
Практика, как известно - критерий истины. В данном случае, критерий прост. Если в момент выбора "Что использовать?" новый реквизит в конфе или дополнительное свойство, ты выбираешь свойство, значит средства работы со свойствами, которыми ты располагаешь, достаточно удобны. Если создаешь реквизит объекта, то тебе надо задуматься над своим инструментарием.
Однажды мне надоело выбирать, и я написал маленькую библиотечку. С тех пор всегда ее пользую и выбираю свойства не задумываясь. В этом нет никакого открытия Америки. Примеров подобных функций в сети много. Возможно, более корректных. Это тоже говорит о том, что тема актуальна и пишу я не зря. Надо просто собраться с духом и поместить эти функции в модуль, который всегда под рукой. И тогда сразу кое-что изменится в подходах к расширению возможностей конфигурации. Привожу свои варианты функций из практических соображений. Пользуюсь ими давно. Никогда не подводили. Уже привык им доверять.
Сам я больше тяготею к использованию дополнительных сведений. Причем, без наборов. В основном использую их для хранения данных порождаемых программой. Поэтому работа с дополнительными реквизитами представлена в библиотеке беднее. Дописывать свежее не стал. Предлагаю только проверенный код. Каждый может доработать под свои нужды сам. Основная цель была не накормить, а научить ловить рыбу. Сорри.
Все функции приведены и описаны в тексте ниже:
1. Собственно - свойство. Суть этой функции в том, чтобы не только получить свойство по имени, но и создать его при отсутствии. Для создания нужно явно указать тип. Можно было создать строку по умолчанию, но остановился на этом варианте. Для большего контроля. Удобство удобством, но и случайное создание свойства из-за ошибки в имени ни к чему.
2. Работа со значением свойства.
3. Локализация объекта по уникальному значению свойства.
4. Создание дополнительного реквизита в наборе.
5. Напоследок, пример использования. Создание необходимых свойств (при отсутствии) при запуске обработки. Пример из моей публикации по СДЭК.
Ну вот и все. Спасибо за внимание. Надеюсь, что публикация будет полезной и кого-нибудь на что-нибудь сподвигнет. Удачи.
Предисловие
Начиная с версии платформы 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 раз подумайте, прежде чем добавлять их в конфигурацию.
Читайте также: