Добрый день
в конфигурациях 1с на чем основан способ использования так называемых ключей аналитики? Используется в частности, в РАУЗ. Также, например, в УТ11 справочник КлючиАналитикиУчетаНоменклатуры.
Может быть есть мат. модель в теории СУБД, причины возникновения итд

Одна из причин-ускорение расчетов за счет создание готовых объектов из нескольких срезов аналитики. Каждый элемент справочника несёт в себе три измерения и считается сразу.

Экономия на индексах

Есть книжка на 100 страниц описания механизма в УПП, думаю логика та же

(1) может быть что один элемент справочника несет типы и значения справочник-справочник-документ. а другой элемент справочника несет типы и значения документ-документ-документ?

(3) скорее "невозможность получать нужные наборы индексов для справочников и регистров накопления".

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

я аналогичную фигню реализовывал когда еще РАУЗ-а не было и в помине :) примерно 10 лет назад ...

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

1. контрагент+документ
2. документ+контрагент
3. Контрагент+Контрагент+Документ
4. организация+физлицо+физ лицо+физ лицо+ контрагент+контрант+контрагент+номенклатура+еще 10 параметров

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

практическое применение довольно широкое :) работает на чтение быстро и стабильно.

сейчас у меня на работе права построены на таком объекте.

(8) "делаем элемент справочника в нем тч тип+значение"
.
а как если для одного надо "контрагент+документ" (2 реквизита), а для другого "контр+контр+документ" - 3 реквизита и т.д.? сколько реквизитов в элементе справочника надо/как?

(8) 10 лет назад рауз уже был

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

(9) в справочнике табличная часть, сколько надо аналитик столько и надо

(8) у тебя только требования по функционалу были, по производительности не было?

(8) @ когда еще РАУЗ-а не было и в помине :) примерно 10 лет назад@

10 лет назад РАУЗ был в само расцвете ))

(13) у меня требования были к скорости чтения, то есть запись медленная а чтение быстрое.

(14) (10) это были 2006...2007 года

(16) + а рауз появился 2008...2009

(16) 2006 год был 15 лет назад ))

(15) а разве не наоборот?
чтение ухудшается за счет соединений нескольких таблиц, в твоем случае из три: основная, ключ, ТЧ ключа
а запись наоборот быстрее т.к. часть ключей уже есть

(18) ну я примерно сказал 10 лет, потом глянул даты работы выходит 2006 год, это я в банке документооборот делал, тогда только вышел ДО 1.0, мы его купили, но он не пошел у нас, пришлось переписывать почти все...

(19) при чтении у тебя уже известен элемент справочника (он как ссылка записывается куда надо, например в документы или в движения), а потом простой джойн по одной ссылке и все...

а вот при записи надо сначало найти ко ТЧ если не найдено создать и потом уже писать...

я тогда использовал текстовый ключ который генерировался из всей аналитики ТЧ в виде мд5 хеша и уже по хешу искал, там были нюансы с сортировками и т.д. и схема вышла "хрен разберешь" но она работала. Сейчас я немного по другому делаю, и теперь и более менее понятно и быстро (за счет некой денормализации)

как бы справочник партия из лохиатого ТиС имеет такую же структуру и назначение

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

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

(24) сущность называется суррогатный ключ

(12) табличная часть к чему? к элементу справочника? и для каждого элемента в справочнике можно задать произвольное количество запсией тип-значение?

(26) да.

справочник у него ТЧ с двумя двумя колонками,

тип значение - ПВХ
значение - Значение ПВХ

далее этот элемет справочника использовался в виде ссылки

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

(24) если не ошибаюсь, это движение в сторону четвертой нормальной формы

(3) А еще защита от криворуких программистов, которые не умеют пользоваться ВЫРАЗИТЬ :)

А вот тому, кто убрал код их ключей аналитики руки бы вырвать надо...

Знаю фирму, где в самописке извращались: вместо двух измерений Товар и Характеристика - сделали одно типа "ключа". Наелись с тормозами, потом переделали нормально.

(32) зачем сделали так? На каких операциях тормозило?

(33) Точно не могу сказать, просто сам факт помню.

(34) может неправильно использовали

кто нибудь делал подобное для оптимизации?

(36) Мы использовали аналогичный подход на 1С:УХ (1.3) что бы в рамках бюджета можно было использовать более 5 аналитик на бюджетных классификаторах с минимально возможным изменением типовой архитектуры. Т.е. в первую очередь преследовали именно функциональные задачи. Дополнительно получили технологический плюс в части экономии места в базе и как следствие регламентные операции (обслуживание индексов, бэкапы и пр.) выполнялись быстрее, чем если бы мы добавили в регистр хранения аналитик еще 8 измерений, что бы можно было в них хранить необходимые аналитики. Аналогично со скоростью записи данных в регистр, в большинстве случаев чем меньше в таблице полей, тем скорость записи быстрее, а новые комбинации аналитик планирования появлялись не так активно, как использовались существующие. У нашего заказчика были достаточно увесистые бюджеты с глубокой детализацией планирования, про фактические бюджеты вообще молчу.