Как спроектировать структуру регистра сведений

Публикация № 1544351 08.11.21

Инструментарий разработчика - Конфигурирование 1С

«Что может быть проще?» — это первое, что приходит в голову. Но что, если это не так? В этой статье мы попробуем затронуть некоторые вопросы, которые могут возникнуть при проектировании больших регистров.

Оглавление

Постановка задачи и интуитивный метод проектирования

Нормализация таблиц

Наиболее важные запросы

Новая структура регистра сведений

Использование индексов

Заключение

Материалы, использованные при подготовке статьи


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

 

Постановка задачи и интуитивный метод проектирования

Давайте начнем с постановки задачи. Допустим, есть некая складская подсистема. Из разговора с заказчиком получаем следующее видение:

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

Анализируем, получаем набор атрибутов, которые должны быть в нашем регистре:

  • Организация
  • Подразделение организации
  • Склад
  • Стеллаж
  • Полка 
  • Секция
  • Ячейка склада 
  • Номенклатура 
  • Характеристика номенклатуры

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

В результате получаем следующую структуру:

  • Измерения
    • Организация
    • Подразделение организации
    • Склад
    • Стеллаж
    • Полка
    • Секция
    • Ячейка склада
    • Номенклатура
    • Характеристика номенклатуры
  • Ресурсы

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

Ниже будут рассмотрены:

  • Нормальные формы БД
  • Проектирование запросов к РС
  • Индексы РС

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

Не ограничивая общности рассуждения, заметим, что:

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

Нормализация таблиц

Нам потребуется привести таблицу ко 2-й нормальной форме. И в этом нам поможет определение функциональной зависимости (ФЗ).

Пусть дано отношение r со схемой (заголовком) R, A и B — некоторые подмножества множества атрибутов отношения r. Множество B функционально зависит от A тогда и только тогда, когда каждое значение множества A связано в точности с одним значением множества B. Обозначается A -> B.

Говоря простым языком, ФЗ — это связь типа «многие-к-одному» между двумя полями одной или двух таблиц. В любой конфигурации такие связи встречаются буквально на каждом шагу. Вот несколько примеров:

  • Подчиненный элемент функционально определяет своего владельца
  • Подчиненный элемент функционально определяет своего родителя
  • Справочник, реквизитом которого является ссылка на другой справочник, например, ЕдиницаИзмерения в Номенклатуре (СправочникСсылка.КлассификаторЕдиницИзмерения) и так далее.

Вспомним определения первой и второй нормальных форм.

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

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

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

Смысл 2НФ в том, чтобы из ключа отношения нельзя было удалить какое-либо поле без потери функциональности. К примеру, у нас есть некая исходная таблица, которая содержит в себе организацию и подразделение организации. При условии, что подразделение организации функционально определяет организацию, если мы удалим подразделение организации из таблицы, то потеряем функциональность. А вот если мы удалим организацию, то с помощью запроса всегда сможем восстановить исходную таблицу. 

Применим это к нашему регистру. Вот список ФЗ:

  • Подразделение организации -> Организация
  • Склад -> Подразделение организации
  • Ячейка склада -> Секция -> Полка -> Стеллаж -> Склад
  • Характеристика номенклатуры -> Номенклатура

Удалив все «лишние» поля из регистра, получим структуру:

  • Измерения
    • Ячейка склада
    • Характеристика номенклатуры
  • Ресурсы

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

ВЫБРАТЬ
	Организация.Ссылка КАК Организация,
	ПодразделениеОрганизации.Ссылка КАК ПодразделениеОрганизации,
	Склад.Ссылка КАК Склад,
	Стеллаж.Ссылка КАК Стеллаж,
	Полка.Ссылка КАК Полка,
	Секция.Ссылка КАК Секция,
	РезервыНаСкладе.ЯчейкаСклада КАК ЯчейкаСклада,
	Номенклатура.Ссылка КАК Номенклатура,
	РезервыНаСкладе.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатуры
ИЗ
	РегистрСведений.РезервыНаСкладе КАК РезервыНаСкладе
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ЯчейкаСклада КАК ЯчейкаСкладаСпр
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Секция КАК Секция
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Полка КАК Полка
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Стеллаж КАК Стеллаж
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Склад КАК Склад
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ПодразделениеОрганизации КАК ПодразделениеОрганизации
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Организация КАК Организация
		ПО ПодразделениеОрганизации.Владелец = Организация.Ссылка
		ПО Склад.Владелец = ПодразделениеОрганизации.Ссылка
		ПО Стеллаж.Владелец = Склад.Ссылка
		ПО Полка.Владелец = Стеллаж.Ссылка
		ПО Секция.Владелец = Полка.Ссылка
		ПО ЯчейкаСкладаСпр.Владелец = Секция.Ссылка
		ПО РезервыНаСкладе.ЯчейкаСклада = ЯчейкаСкладаСпр.Ссылка
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатурыСпр
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК Номенклатура
		ПО ХарактеристикаНоменклатурыСпр.Владелец = Номенклатура.Ссылка
		ПО РезервыНаСкладе.ХарактеристикаНоменклатуры = ХарактеристикаНоменклатурыСпр.Ссылка


Определенно, в этом подходе что-то есть, но назвать результат оптимальным затруднительно.

Наиболее важные запросы

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

Первый запрос

Есть некий документ, какое-то резервирование, которое соединяется с нашим регистром сведений по подразделению организации. 

ВЫБРАТЬ
	Резервирование.Ссылка КАК Ссылка,
	Резервирование.ПодразделениеОрганизации КАК ПодразделениеОрганизации,
	ПодразделенияСкладыНоменклатура.Склад КАК Склад,
	ПодразделенияСкладыНоменклатура.ЯчейкаСклада КАК ЯчейкаСклада,
	ПодразделенияСкладыНоменклатура.Номенклатура КАК Номенклатура,
	ПодразделенияСкладыНоменклатура.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатуры
ИЗ
	Документ.Резервирование КАК Резервирование
	ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПодразделенияСкладыНоменклатура КАК ПодразделенияСкладыНоменклатура
		ПО (Резервирование.ПодразделениеОрганизации = ПодразделенияСкладыНоменклатура.ПодразделениеОрганизации)
ГДЕ
	Резервирование.Ссылка = &Ссылка

Второй запрос 

Соединение по складу некого документа и регистра сведений.

ВЫБРАТЬ
	Резервирование.Ссылка КАК Ссылка,
	Резервирование.Склад КАК Склад,
	ПодразделенияСкладыНоменклатура.Номенклатура КАК Номенклатура,
	ПодразделенияСкладыНоменклатура.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатуры,
	ПодразделенияСкладыНоменклатура.ПодразделениеОрганизации КАК ПодразделениеОрганизации,
	ПодразделенияСкладыНоменклатура.ЯчейкаСклада КАК ЯчейкаСклада
ИЗ
	Документ.Резервирование КАК Резервирование
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПодразделенияСкладыНоменклатура КАК ПодразделенияСкладыНоменклатура
		ПО (Резервирование.Склад = ПодразделенияСкладыНоменклатура.Склад)
ГДЕ
	Резервирование.Ссылка = &Ссылка

Третий запрос 

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

ВЫБРАТЬ
	РезервированиеТовары.Номенклатура КАК Номенклатура,
	РезервированиеТовары.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатуры,
	РезервированиеТовары.Количество КАК Количество,
	ПодразделенияСкладыНоменклатура.ПодразделениеОрганизации КАК ПодразделениеОрганизации,
	ПодразделенияСкладыНоменклатура.Склад КАК Склад,
	ПодразделенияСкладыНоменклатура.ЯчейкаСклада КАК ЯчейкаСклада
ИЗ
	Документ.Резервирование.Товары КАК РезервированиеТовары
	ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПодразделенияСкладыНоменклатура КАК ПодразделенияСкладыНоменклатура
		ПО (РезервированиеТовары.Номенклатура = ПодразделенияСкладыНоменклатура.Номенклатура
		И РезервированиеТовары.ХарактеристикаНоменклатуры = ПодразделенияСкладыНоменклатура.ХарактеристикаНоменклатуры)
ГДЕ
	РезервированиеТовары.Ссылка = &Ссылка

Новая структура регистра сведений

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

  • Измерения
    • Подразделение организации
    • Склад
    • Ячейка склада
    • Номенклатура
    • Характеристика номенклатуры
  • Ресурсы

Использование индексов

Одной из типичных причин неоптимальной работы запросов считается несоответствие индексов и условий запроса. В известной статье на ИТС предлагается изменить условия таким образом, чтобы оптимизатор запросов сервера SQL мог использовать индексы. В нашем случае надо пройти обратной дорогой — от условий к индексам. Это не такая очевидная задача из-за особенностей создания индексов сервером приложений 1С.

Проектирование индексов. Попытка 1

Попробуем решить задачу «в лоб» и просто добавим индексирование тем полям, которые участвуют в условиях запроса.

  • Измерения
    • Подразделение организации (cluster index) 
    • Склад (index)
    • Ячейка склада
    • Номенклатура (index)
    • Характеристика номенклатуры (index)
  • Ресурсы

Первый запрос будет использовать кластерный индекс, второй — индекс по полю Склад. А третий, скорее всего — сканирование кластерного индекса с предикатом WHERE:(), потому что не найдет такого индекса, где бы участвовала и номенклатура, и ее характеристика.

Проектирование индексов. Попытка 2

Немного изменим порядок полей:

  • Измерения
    • Номенклатура (cluster index)
    • Характеристика номенклатуры (cluster index)
    • Подразделение организации (index)
    • Склад (index)
    • Ячейка склада
  • Ресурсы

В этом случае есть шанс, что все три запроса найдут каждый свой эффективный индекс.

Подтверждение результатов проектирования

Индексы

До сих пор мы использовали исключительно теоретические рассуждения. Они достаточны в случае нормализации таблиц и оптимизации структуры регистра под запросы. Но проверить использование индексов при исполнении запросов можно, только создав структуру. Для этого был реализован демонстрационный пример на платформе 8.3.18 и MS SQL Server. Со стороны 1С индексы выглядят следующим образом:

Очень похоже на нужный нам результат, но хотелось бы окончательных доказательств. Фактических. Настоящих. Брони!

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

 

Из него абсолютно точно понятно, что первый индекс — кластерный, остальные — уникальные, а на ИТС пишут правду и ничего кроме.

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

Для получения планов запросов была использована известная обработка:

 

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

 

Запрос 1: соединение по подразделению

ВЫБРАТЬ
…
ИЗ
Документ.Резервирование КАК Резервирование
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПодразделенияСкладыНоменклатура КАК
ПодразделенияСкладыНоменклатура
ПО (Резервирование.ПодразделениеОрганизации =
ПодразделенияСкладыНоменклатура.ПодразделениеОрганизации)
|--Index Seek (OBJECT:(РегистрСведений.ПодразделенияСкладыНоменклатура.
[Индекс по ПодразделениеОрганизации, Номенклатура,
ХарактеристикаНоменклатуры, Склад, ЯчейкаСклада]
AS [T2]), SEEK:([T2].[ПодразделениеОрганизации]=Документ.Резервирование.
[ПодразделениеОрганизации]
as [T1].[ПодразделениеОрганизации]) ORDERED FORWARD)

Запрос 2: соединение по складу

ВЫБРАТЬ
...
ИЗ
Документ.Резервирование КАК Резервирование
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПодразделенияСкладыНоменклатура КАК
ПодразделенияСкладыНоменклатура
ПО (Резервирование.Склад = ПодразделенияСкладыНоменклатура.Склад)
|--Index Seek (OBJECT:(РегистрСведений.ПодразделенияСкладыНоменклатура.[Индекс
по Склад, Номенклатура, ХарактеристикаНоменклатуры,
ПодразделениеОрганизации, ЯчейкаСклада] AS [T2]), SEEK:([T2].
[Склад]=Документ.Резервирование.[Склад] as [T1].[Склад]) ORDERED FORWARD)

Запрос 3: соединение по номенклатуре и характеристике номенклатуры

ВЫБРАТЬ
...
ИЗ
Документ.Резервирование.Товары КАК РезервированиеТовары
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПодразделенияСкладыНоменклатура КАК
ПодразделенияСкладыНоменклатура
ПО (РезервированиеТовары.Номенклатура =
ПодразделенияСкладыНоменклатура.Номенклатура
И РезервированиеТовары.ХарактеристикаНоменклатуры =
ПодразделенияСкладыНоменклатура.ХарактеристикаНоменклатуры)
 
План запроса:
|--Clustered Index Seek (OBJECT:(РегистрСведений.ПодразделенияСкладыНоменклатура.
[Индекс по Номенклатура, ХарактеристикаНоменклатуры,
ПодразделениеОрганизации, Склад, ЯчейкаСклада] AS [T2]), SEEK:([T2].
[Номенклатура]=Документ.Резервирование.Товары.[Номенклатура] as [T1].[Номенклатура]
AND [T2].[ХарактеристикаНоменклатуры]=Документ.Резервирование.Товары.
[ХарактеристикаНоменклатуры] as [T1].[ХарактеристикаНоменклатуры]) ORDERED
FORWARD)

Как можно видеть, во всех трех случаях оптимизатор использовал операторы Index Seek без предиката WHERE. Это именно тот результат, который планировался изначально.

Заключение

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

Полученный результат нетривиален, но закономерен. В этом можно убедиться, если посмотреть, например, УТ 11. Вот несколько регистров из нее:

 

Материалы, использованные при подготовке статьи

 

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Yashazz 4117 08.11.21 13:00 Сейчас в теме
После регистра с 90 измерениями, кажется, или ресурсами, в ЗУП, я уже ничему не удивляюсь.
6. m_aster 100 08.11.21 19:50 Сейчас в теме
(1)
Залез в ЗуП, посмотрел, есть такой регистр сведений "Настройки расчета зарплаты (расширенный)", 107 ресурсов. Это регистр настроек, у него всего одна запись, измерений нет, нагруженность на систему нулевая.
triviumfan; +1 Ответить
18. Yashazz 4117 09.11.21 14:59 Сейчас в теме
(6) ага, вроде он самый
и это сегодня одна запись, а завтра хз чего может быть)
sasha777666; +1 1 Ответить
20. m_aster 100 09.11.21 18:48 Сейчас в теме
(18)
Вы ж где-то упоминали, что на эксперта сдавали)) Попробуйте просто добавить еще одну запись регистру без измерений. (Это вопрос по теме регистры из Профессионала по платформе)
38. Yashazz 4117 11.11.21 12:26 Сейчас в теме
(20) а я просто не помню, были там измерения или нет, и ЗУП под рукой нет, чтоб глянуть
да и неинтересно
sasha777666; +1 1 Ответить
40. m_aster 100 11.11.21 16:07 Сейчас в теме
(38)Ну да, ну да. И эксперт может забыть, не помнить или просто не знать. Бывает)
41. Yashazz 4117 11.11.21 16:50 Сейчас в теме
(40) Верно, эксперт не тот, кто помнит наизусть всю структуру метаданных конфигурации, а кто умеет при необходимости быстро в ней разобраться)
sasha777666; +1 1 Ответить
42. m_aster 100 11.11.21 17:54 Сейчас в теме
(41) И скромный. Для этого совсем не обязательно быть экспертом, нужно иметь правильное мышление и любить программирование и 1С в частности. Сколько этих "специалистов" с сертификатами теряющихся в нетривиальной ситуации. Мы обсуждаем конкретный регистр, с вполне обоснованной структурой. И если Вы говорите, что Вы эксперт, то Ваши слова воспринимаются несколько иначе, чем слова начинающего программиста. К примеру, что добавить запись в регистр без измерений можно может сказать начинающий знакомиться с 1С человек, но никак не эксперт.
IgorS; echo77; +2 1 Ответить
10. biimmap 317 09.11.21 10:29 Сейчас в теме
(1) я вот тоже чё-т не знаком с таким волшебным регистром. Раньше самый страшный был адресный классификатор. Сейчас вроде привели его в норму
2. ImHunter 228 08.11.21 13:32 Сейчас в теме
Какая-то путаница в описании логики появления индексов.
Для измерения №1 не создается кластерный индекс. Кластерный индекс создается по всем измерениям + период. Измерению №1 просто повезло больше всех.
Для остальных измерений индексы тоже просто так не появляются - появятся, если поставить измерению признак Ведущее или Индексировать.

Также, не описан (или хотя бы упомянут) принцип организации измерений на аналитиках (а-ля РАУЗ).
Sevt_RND; m_aster; Rustig; TMV; zqzq; apk-agroeco; Serg O.; t278; +8 Ответить
32. Neti 1684 10.11.21 13:50 Сейчас в теме
(2) Лучшее описание логики формирования индексов находится на ИТС.
Если мы правильно поняли про РАУЗ, то Вы говорите про то, что некоторый набор измерений заменяется ссылкой на элемент справочника?
Если да, то это одно из возможных архитектурных решений. Есть финальное и окончательное решение этой задачи. Можем рассмотреть!
3. Andreynikus 1420 08.11.21 17:01 Сейчас в теме
Два кластерных индекса в примере, видимо опечатка ))
И во втором запросе у вас соединение снова по подразделению, а нужно по складу.
А так очень даже хорошая статья, спасибо.
23. TMV 14 10.11.21 10:05 Сейчас в теме
(3)Такое (как у автора) описание вообще не корректно. Индекс он не на поле, а на совокупность полей.
30. Neti 1684 10.11.21 13:44 Сейчас в теме
(3) Спасибо за указание ошибки в запросе. Но второй кластерный где?
31. Andreynikus 1420 10.11.21 13:47 Сейчас в теме
(30)
Вот здесь > Проектирование индексов. Попытка 2

И было бы удобно указать состав индекса, что кластерный он не из одного поля состоит, да и не кластерный тоже не из одного поля.
44. Neti 1684 12.11.21 16:40 Сейчас в теме
(31) Здесь проблема в изложении. В материале автор хотел подчеркнуть, что номенклатура и ее характеристика попадут в состав кластерного индекса. Также это относится и к прочим обозначениям.
4. malikov_pro 967 08.11.21 17:46 Сейчас в теме
Почему в размышлениях не дошли до ключа аналитики (примеры есть в УТ 11)? Сначала получаем таблицу ключей по индексам, а после к полученной таблице присоединяем данные из регистра, на сколько понимаю СКД делает это "под капотом".
24. rovenko.n 10.11.21 10:41 Сейчас в теме
(4)
не дошли до ключа аналитики

Я так понимаю, потому что это уже второй вопрос.
29. Neti 1684 10.11.21 13:42 Сейчас в теме
(4) Вы правы, но такое решение — материал отдельной статьи из-за большого количества особенностей применения.
5. m_aster 100 08.11.21 19:48 Сейчас в теме
Глядя на постановку задачи в разрезе именно регистра сведений, как объекта соответствия объектов другу другу, на мой взгляд логичнее номенклатуру с ее свойствами использовать в качестве ресурса и получать соответствие хранения в разрезе Организаций, Подразделений, Складов, Ячеек и т.д. Также, конечно, имеет значение в каком виде заказчик хочет получать данные в разрезе указанных объектов(порядок полей в отчете и т.д.) И Вы указываете на примеры регистров накопления из УТ. Приведите пример, если возможно, из УТ же, регистра сведений, если такой есть подходящий для ваших целей. Эти регистры решают задачи количественного учета в разрезе измерений как в них указано. Подходят в качестве примера(надеюсь, Вы для этих целей их привели в пример) больше для эффективно построенной структуры разрезов и соответственно эффективной выборки с использованием и методики указанной в ИТС(элементарный порядок полей и соответственно эффективности индексов) и вашей методики с учетом анализа эффективности планов запроса.
28. Neti 1684 10.11.21 13:40 Сейчас в теме
(5) Все так, но мы хотели показать не конкретное решение, а последовательность рассуждений. Добавьте к любой постановке задачи всего одно условие и вероятно получите другую структуру.
34. m_aster 100 10.11.21 15:00 Сейчас в теме
(28)
Вы же приводите пример не просто для набора регистров, а в "прикладности" этого примера к конкретной задаче заказчика. И хорошо, чтобы так это было. Ведь это может кому-то пригодиться в жизни, на практике. Так и строить решение, я считаю, необходимо с точки зрения практической реализации, чтобы оно работало эффективно и, самое главное, практично. Для того заказчика, которого Вы приводите в пример в начале статьи. И разница все же есть между ресурсом и измерением, Вы ж сами понимаете. И тем более, если приводите регистры накопления в пример, поясните зачем. Они предназначены для решения несколько иных задач.
45. Neti 1684 12.11.21 16:42 Сейчас в теме
(34) Спасибо за критику, учтем в следующих публикациях.
46. Rustig 1292 14.11.21 11:49 Сейчас в теме
(45) ага, слабовата статья...
...вначале абстракция на абстракции - так сложно описан принцип нормализации таблиц - так лучше не читать такое описание - лучше классиков почитать ....
...постановка задач - клиент чихнул - и сразу регистр структурируем - а потом идем к клиенту и задаем вопросы - а зачем это надо было? - какой-то выдуманный пример - в жизни 100 раз узнаем зачем это надо, как устроено уже сейчас - и только потом предлагаем решение с ее архитектурой....
... а этот план запроса... в непонятной консоли запросов - и зачем? чтобы узнать будет индекс кластерным или нет?
ни разу за 10 лет не использовал план запроса, коллеги, при проектировании регистров... и в данном примере не увидел зачем его использовать - сложно все объясняется....
"системный архитектор проделывает работу" - по моему не раскрыт смысл какую-такую работу должн делать сист.архитектор ,
"смотрите в УТ - там нетривиально" - по моему тривиально - под каждую учетную задачу свой регистр - я об этом 5 лет назад писал....
вы на УТ смотрите одномоментно... Как будто у нее не было своей истории развития - когда регистры, взаимосвязи, индексы, запросы менялись во времени ....
m_aster; zaic; Yashazz; +3 Ответить
56. m_aster 100 15.11.21 00:54 Сейчас в теме
(45) Да не за что. За меня уже ответил коллега, спасибо ему. Просто при прочтении в самом начале споткнулся о структуру. Пробежал по статье, в конце увидел регистры накопления с задачей никак не связанные, соответственно в качестве резюме высказал свое видение. Кстати, насчет УТ, в ней есть такой регистр сведений - "Аналитика учета номенклатуры". Он, конечно для других целей, просто оцените его структуру, это практически то, что я Вам показал. Это в качестве технической, не предметной, реализации, по смыслу Вашей статьи, т.к. Вы описываете необходимость оптимальной выборки данных и т.д.
7. e-9 47 08.11.21 20:59 Сейчас в теме
"Наиболее важные запросы": мне одному показалось, что Первый запрос и Второй запрос - идентичны?
Прикрепленные файлы:
9. Neti 1684 09.11.21 10:24 Сейчас в теме
(7) исправили, спасибо за внимательность)
8. milkers 2542 09.11.21 08:17 Сейчас в теме
Мелкий ляп. Характеристика может не определять конкретную номенклатуру. Характеристики номенклатуры может и не быть.
27. Neti 1684 10.11.21 13:40 Сейчас в теме
(8) Пустая ссылка — тоже ссылка, но просто пустая)
47. Rustig 1292 14.11.21 11:51 Сейчас в теме
(27) вы не поняли сути замечания... ваш ответ - некорректен
RocKeR_13; sasha777666; +2 Ответить
11. biimmap 317 09.11.21 10:38 Сейчас в теме
Необычный путь определения структуры регистра.

Если надо, чтоб реально все 10 полей что-то значили и были в измерениях, то надо вводить понятие Ключ аналитики (в ЕРП ещё пару лет назад было такое! сейчас не в курсе). и тогда вместо 9 измерений останется 5. Аналитику можно назвать Место хранения, в неё запихнуть всё остальное. обязательное поле только склад.

Зачем столько индексов тоже не совсем ясно. В целом структура регистра и состав индексов определяется тем, как используется регистр! И это надо знать сразу, т.е. не какие-то странные вариации запросов писать надо, а сразу думать где и какие будут реальные запросы.

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

Добавьте в статью мысль о том, что если у Вас 10 измерений в регистре, Вы 100% сделали неверно! ну или пусть 99%. Норма для регистров сведений и накопления - 5 измерений.
m_aster; Rustig; +2 Ответить
26. Neti 1684 10.11.21 13:39 Сейчас в теме
(11) Лучшее — враг хорошего. Но за мысль про 5 измерений — спасибо огромное!
48. Rustig 1292 14.11.21 11:53 Сейчас в теме
(11) Браво, Павел! Браво!
12. ImHunter 228 09.11.21 12:11 Сейчас в теме
(4) (11) С аналитиками тоже неоднозначно.
Для регистров накопления это хорошо сработает. Но вот для регистров сведений, особенно, для независимых, про аналитики нужно серьезно думать. Ведь по ним нужно будет устанавливать отборы наборов записей и блокировки. И тут от аналитики потребуется, чтобы она хорошо "кластеризовала" данные - не мелко, но и не слишком крупно.
Yashazz; Rustig; +2 Ответить
13. biimmap 317 09.11.21 12:28 Сейчас в теме
(12) Давай разделим на 2 части:
1. Поиск аналитики
2. Установка отбора.

Что такое поиск аналитики? Это простой запрос к справочнику. Никаких проблем такой запрос обычно не представляет даже при большом количестве записей (возьмем для примера справочник номенклатура. там и до млн и больше бывает).

А уже когда мы получили аналитику, то простое условие КлючАналитики В (&СписокАналитик) тоже срабатывает эффективно, если правильно учтены индексы.

Не думаю, что здесь есть место для проблем) а вот 10 измерений это сразу проблема!
14. ImHunter 228 09.11.21 12:33 Сейчас в теме
(13) С запросом - вообще нет проблем. А вот с установкой отбора - есть проблемы. Если аналитика будет мельчить, то придется в несколько порций обрабатывать данные.
15. biimmap 317 09.11.21 12:38 Сейчас в теме
(14) с установкой отбора где? Посмотри как в ЕРП это работает. смысл это обсуждать!? Механизм абсолютно рабочий.
16. ImHunter 228 09.11.21 12:44 Сейчас в теме
(15) Как где - в наборе записей РС.
Причем тут ERP? Регистры сведений, даже с аналитиками, - это не особенность ERP.
Ну и я не жажду пообсуждать далее что-то. Просто обозначил моменты работы с аналитиками.
Если пользуешься готовым решением (в ERP, например), то особо про это ведь и не думаешь - "Механизм абсолютно рабочий". Но вот когда сам начнешь что-то "а-ля аналитики" делать, вот тогда и понатыкаешься на необходимость все взвесить.
17. biimmap 317 09.11.21 12:48 Сейчас в теме
(16)
в наборе записей РС.


Согласись это очень странный регистр сведений на 10 измерений да ещё и без регистратора!? Тяжко придумать столь глупую задачу! Поэтому если подходить с точки зрения подчинённых регистров - проблем нет. Просто есть дополнительный запрос/процедура для подбора/создания аналитик. Вот и вся проблема.
49. Rustig 1292 14.11.21 11:58 Сейчас в теме
(16), (17) - вы о разном говорите, но вы оба правы - это история о том, когда мудрецы с закрытыми глазами ощупывают слона с разных сторон - и каждый свое ощущение озвучивает....
55. ImHunter 228 14.11.21 14:30 Сейчас в теме
(49) Так мы и не статью рождаем, а обсуждаем аспекты.
60. biimmap 317 15.11.21 14:52 Сейчас в теме
(49) с разных сторон у слона длина хобота разная)))
19. Yashazz 4117 09.11.21 15:01 Сейчас в теме
Правильность регистра, как и любого объекта метаданных - это в значительной степени правильность проектирования процессов с учётом нагрузок и развития, а это, в свою очередь, методологическая и аналитическая проработка. Так что ответ на вопрос, вынесенный в заголовок, элементарен: методически грамотно исследовать автоматизируемую область, построить внятную реалистичную модель и прогнозы. Всё. Без этого все знания о всяких там индексах-шминдексах ничего не стоят.
21. buganov 184 10.11.21 09:57 Сейчас в теме
(19) Вы где-нибудь видели, чтобы можно было построить методологию, ну хотя бы на месяц вперед, не говоря о более длинном периоде?
Если конфигурация очень активно изменяется, то аналитическая проработка на будущее ничего не стоит, ибо даже после проработки десять раз может и бизнес-процесс измениться, и смежные процессы могут в определенный момент начать использовать регистр.
И как определить нагрузку? На каждый регистр писать нагрузочное тестирование?
И вопрос проектирования вообще не элементарен в highload сегменте, тут помимо правильности проектирования структуры и индексов в конфигураторе имеет смысл заложить основу для универсального использования.
И знания об индексах стоят очень дорого. Точнее незнания.
Petr54-ru; +1 Ответить
39. Yashazz 4117 11.11.21 12:38 Сейчас в теме
(21) Детский сад. Я вам ссылки конкретные накидывать не буду, но даже на ИС неоднократно публиковали подходы, позволяющие построить методологию на длительный период. Мало какой бизнес-процесс и мало какая предметная область изменяется с такой скоростью, чтоб её методологическая проработка и модель устарели бы за месяц или даже год. Иначе мне даже странно, как же это все берутся автоматизировать то, что через месяц всё напрочь деактуализируется?

Если конфигурация очень активно изменяется, это значит одно из двух. Или это плохо продуманное, плохо подготовленное, плохо согласованное обследование автоматизируемого предмета, ТЗ и техпроекта, плюс "пионэрская" команда, которая с радостным энтузиазмом "пилит", не столько конфу, сколько проект и деньги, или это автоматизация чего-то волшебного, где "десять раз бизнес-процесс может измениться". Приведите пример, а? Я прям заинтригован.

Да, можно и на каждый регистр. Опять же, были тут "взрослые" статьи на эту тему. По-серьёзному, ткскзть.

Универсальность - палка о двух концах. Знающие знают, незнающим желаю мягкой рукоятки граблей. Мне расписывать некогда)

Знания об индексах не стоят ни-че-го, если на более раннем этапе не продуман весь подход. Имхо, очевидно. А если неочевидно, так я вам пример приведу: вы можете заложить крутой индекс, кажущийся вам правильным порядок измерений итд, но вас это нифига не гарантирует от а) колебаний селективности, т.е. наполнения БД, б) пустых значений, в) записей регистра эдаким образом, что эскалация блокировок дорастает до четверти всей таблицы СУБД, г) элементарно тупых запросов в циклах и прочей пакости. И пункты в) и г) не оттого возникнут даже, что руки кривые, а оттого, что казалось изначально, будет это редко, а процесс пошёл так, что в хвост и гриву каждую минуту стопицот вызовов.
Rustig; kalyaka; +2 3 Ответить
43. buganov 184 11.11.21 18:42 Сейчас в теме
(39) Надо бы тут проветрить, а то душновато. Yashazz, почему когда Вы приходите в комментарии становится так душно?
Отвечаю теперь.
Куда нам, команде пионэров, до Вас то, мы же детский сад =)
Я больше, чем уверен, что Вы помимо самовлюбленных комментариев не могли не наткнуться на понятия каскадная и спринтовая разработка. Так вот, когда команда автоматизирует спринтами текущие и новые бизнес-процессы, откуда она может знать, какие процессы будут в будущем? Пример привести? Да пжалста. Есть условная торговая сеть. Довольно крупная, хоть и далеко не Х5. И вот в этой сети решили обкатать маркетинговые акции. Да так зашло, что все офигели и давай на фундаменте творить чудеса маркетинга. И ничего тут волшебного, как Вам может показаться. И более того, никакого распила, просто бизнес растет, с бизнесом растет потребность в доработках, в том числе глубокой интеграцией в действующие механизмы.
ТЗ, техпроект, обследование, Вы точно работали с крупным бизнесом или где-то что-то читали? Я Вам вот что скажу. Я работал с многими компаниями корп сегмента, и там где конкуренция очень высокая, там постоянно все меняется на ходу. Фишки вводятся, нерабочие механизмы отваливаются. И времени на составление красивых слов не хватает. В проектных офисах топовых франчей да, но это бумажка, без которой потом заказчику не доказать, что не верблюд. Да и к тому же работа ведется по каскадной схеме как правило.

И в конечном параграфе Вы свалили в кучу коней и людей и к тому же, как Ваша магическая методология поможет в
а) колебаний селективности, т.е. наполнения БД, б) пустых значений, в) записей регистра эдаким образом, что эскалация блокировок дорастает до четверти всей таблицы СУБД, г) элементарно тупых запросов в циклах и прочей пакости

?
А никак.

Хотя, не совсем никак. Бизнес дяди Ашота, торгующего помидорами, неизменчив. Методология строится легко и просто. И даже архитектуру менять не придется с течением времени. Но как только бизнес начинает агрессивно внедрять в свои процессы новые идеи, поверьте, Вы захлебнетесь писать и переписывать доку.
Надеюсь на Ваше благоразумие и Вы не станете мне что-то доказывать с пеной у рта.
51. Rustig 1292 14.11.21 12:16 Сейчас в теме
(43)
Я больше, чем уверен, что Вы помимо самовлюбленных комментариев

я вот не увидел самовлюбленность.... по-моему мнению, хорошая критика на вес золота, если хотите расти профессионально...
(43)
Пример привести? Да пжалста. Есть условная торговая сеть. Довольно крупная, хоть и далеко не Х5. И вот в этой сети решили обкатать маркетинговые акции. Да так зашло, что все офигели и давай на фундаменте творить чудеса маркетинга. И ничего тут волшебного, как Вам может показаться. И более того, никакого распила, просто бизнес растет, с бизнесом растет потребность в доработках, в том числе глубокой интеграцией в действующие механизмы.
ТЗ, техпроект, обследование, Вы точно работали с крупным бизнесом или где-то что-то читали?

Как раз-таки индексы вам не помогут тут, вы просто не успеете технично проверить индексы, оптимальность архитектуры и запросов, утонете в таком анализе, как предложено в статье.
Чтобы участвовать в проектах уровня Х5 - вам нужен богатый опыт.
Чтобы программировать на 1с -знание об индексах должны быть - на ИТС много подходящего материала.
Но чтобы участвовать в проектах Х5 нужен опыт, и наверное один из главных опытов - это видеть наперед как будет меняться архитектура со временем.
ПС. Не принимайте любую критику близко к сердцу.
https://www.youtube.com/watch?v=BFD9BL6tYB8
57. Yashazz 4117 15.11.21 08:12 Сейчас в теме
(51) Целиком согласен. И настоящий опыт, набитые шишки, во сто крат ценнее прочитанного Филиппова и сертификатов всяких там. Точнее даже не только опыт, а ещё интуиция, определённое чувство, позволяющее выбрать магистральный путь или применить мелкую фишку тогда, когда разумное обоснование ещё затруднено.
59. buganov 184 15.11.21 10:25 Сейчас в теме
(51) ну так я и говорю, что такие мегаобследования ни к чему не приведут. И индекс лепить, чтобы один запрос работал, ну такое себе развлечение. Я писал про то, что Yashazz предлагает вести тотальную бюрократию, тщательно прорабатывать наперед бизнес-процессы. Соглашусь, что архитектуру можно спрогнозировать в разных сценариях, но все может пойти прахом, если фишка не взлетела. Соглашусь лишь, что иногда не хватает документации, но в целом, не критично.
58. Yashazz 4117 15.11.21 08:19 Сейчас в теме
(43)
Я работал с многими компаниями корп сегмента, и там где конкуренция очень высокая, там постоянно все меняется на ходу. Фишки вводятся, нерабочие механизмы отваливаются. И времени на составление красивых слов не хватает. В проектных офисах топовых франчей да, но это бумажка, без которой потом заказчику не доказать, что не верблюд.

Верю. Но это ведь означает только лишь, что у них там в самом бизнесе, пардон, бардак. Что брызжущие инициативой "эффективные менеджеры" постоянно играют в активность. На эту тему Белокаменцев очень хорошо всё уже расписал. Бизнес-процессы не прописаны, не проработаны, взаимодействие сотрудников ниже плинтуса, постоянные реформы реформ... Такую область вообще трудно (а главное, бесполезно) автоматизировать. Причём да, это и в бизнесе, и в госсекторе бывает. Это общая беда, и её корень гораздо глубже, чем наши ТЗ или шило в попе ответственного инициатора. И да, если уж такое делать в 1С, то только постоянные переделки плюс, возможно, быстро адаптируемые универсалы. Но вам не кажется, что когда на уровне министерства каждый квартал меняется "видение задачи", это натуральный бардак? И что уж в этом-то случае не до индексов бывает, пилят - вот как "Платон" из УПП второпях лепили - абы как?
50. Rustig 1292 14.11.21 12:01 Сейчас в теме
(21) Методология - берется из жизни - десятилетиями бизнес-процессы существовали, уже наработан богатый опыт в описании любых учетных задач...
+ все мы видим сейчас - как проектируется маркировка, прослеживаемость товаров, ковидные изменения в зарплатном учете... ничего в этом страшного нет - пусть процессы меняются, но основа уже есть...
25. kalyaka 737 10.11.21 11:19 Сейчас в теме
(19) Здесь речь идет про проектирование под высоконагруженные задачи. Исходя из утверждения Дональда Кнута "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. -- DonaldKnuth" - это для примерно для 3% задач бизнеса :)

Хотелось бы конечно почитать про ключи аналитик, про преодоления ограничения периодичности в 1 секунду, про задачу уникальности сочетания измерений, про включение и выключение действия периодического регистра и т.д. - т.е. про остальные 97% задач, которые могут решаться на регистрах сведений :)
52. Rustig 1292 14.11.21 12:20 Сейчас в теме
(25)
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.


ну если это Кнут сказал... тогда это Истина....
...не знал, что Кнут считал также , как и я ...
22. buganov 184 10.11.21 10:00 Сейчас в теме
(0) Интересно, а почему в заголовке и в статье проектирование регистра сведений, а примеры из типовых из регистра накопления?
53. Rustig 1292 14.11.21 12:20 Сейчас в теме
33. kuzyara 1209 10.11.21 14:54 Сейчас в теме
И не ответили на самый первый-препервый вопрос, который нужно задать перед проектированием регистра сведений, который вдруг может оказаться на самом деле справочником: "А нужна ли нам ссылка?")
Rustig; Yashazz; +2 Ответить
35. kalyaka 737 10.11.21 16:33 Сейчас в теме
Изначально регистры сведений нужны были для хранения истории значений. Появление непериодических регистров расширило их семантику, теперь это еще и таблицы уникальных значений по измерениям. В последнем случае семантика Ресурсов и Реквизитов стала несколько размытой и тут как раз можно было бы предложить свою трактовку применения этих свойств регистра сведений.

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

Ну и конечно про ссылочные объекты порассуждать. Всегда ли все так однозначно? Вспомните как в ЗУПе был реализован вначале регистр сведений Сотрудники организаций, а затем еще появился и одноименный справочник. А может вместо ссылочного объекта использовать простой тип? Когда такое может быть оправдано?
Rustig; Yashazz; +2 Ответить
54. Rustig 1292 14.11.21 12:26 Сейчас в теме
(35) Браво, Андрей!
Как много опыта высказано в трех абзацах!
Бальзам для души!
36. m0zg153 25 11.11.21 10:34 Сейчас в теме
Подскажите где взять такую консоль запросов, как использована в статье?
Оставьте свое сообщение

См. также

Готовые механизмы 1С: ЗУП, представления

Зарплата Расчетные механизмы v8 v8::СПР ЗУП3.x БУ Бесплатно (free)

Здесь будет храниться архив запросов, которые могут помочь разработчику правильно строить отчеты и получать данные в 1С: ЗУП. Статью буду периодически дополнять.

03.11.2021    1720    Margo462    17    

Моделирование в 1С:ERP - практика анализа движений документов

Анализ учета Механизмы оперативного учета v8 ERP2 Россия УУ Бесплатно (free)

Практические примеры разных вариантов анализа движений документов при моделировании в 1С:ERP - анализ цепочки документов, функциональный анализ, сценарный и событийный.

01.11.2021    1048    pma_2015    9    

Новая упрощенная процедура перерасчета записей регистров расчета (пример)

Расчетные механизмы v8 1cv8.cf Россия Бесплатно (free)

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

24.03.2021    646    galexmvs    5    

Несколько групп для одной номенклатуры в УТ 11

Механизмы оперативного учета Учет ТМЦ v8 v8::ОУ УТ11 Россия УУ Бесплатно (free)

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

23.09.2020    1866    malikov_pro    14    

Регистры бухгалтерии. Настройки, субконто и движения с субконто

Бухгалтерский учет Механизмы бухгалтерского учета v8::БУ Бесплатно (free)

Описание основных настроек регистров бухгалтерии, работы виртуальных таблиц "Субконто" и "Движения с субконто" и кое-что еще.

10.02.2020    24853    YPermitin    13