Вход | Регистрация
 

На чем базируется использование ключей аналитики в конфигурациях 1С?

На чем базируется использование ключей аналитики в конфигурациях 1С?
Я
   vi0
 
15.03.20 - 08:18
Добрый день
в конфигурациях 1с на чем основан способ использования так называемых ключей аналитики? Используется в частности, в РАУЗ. Также, например, в УТ11 справочник КлючиАналитикиУчетаНоменклатуры.
Может быть есть мат. модель в теории СУБД, причины возникновения итд
   МимохожийОднако
 
1 - 15.03.20 - 08:48
Одна из причин-ускорение расчетов за счет создание готовых объектов из нескольких срезов аналитики. Каждый элемент справочника несёт в себе три измерения и считается сразу.
   Cyberhawk
 
3 - 15.03.20 - 11:04
Экономия на индексах
   Krendel
 
4 - 15.03.20 - 11:48
Есть книжка на 100 страниц описания механизма в УПП, думаю логика та же
   Злопчинский
 
5 - 15.03.20 - 13:27
(1) может быть что один элемент справочника несет типы и значения справочник-справочник-документ. а другой элемент справочника несет типы и значения документ-документ-документ?
   ta_da
 
6 - 15.03.20 - 13:54
(3) скорее "невозможность получать нужные наборы индексов для справочников и регистров накопления".
   Сияющий в темноте
 
7 - 15.03.20 - 15:17
независимость механизма расчета от способов учета и разделения на сущности.
в итоге,как бы не выбирали серии,партии и т.п.доя номенклатуры учет ведется по виртуальному справочнику номенклатуры,где каждый элемент уникален.
   vde69
 
8 - 15.03.20 - 15:33
я аналогичную фигню реализовывал когда еще РАУЗ-а не было и в помине :) примерно 10 лет назад ...

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

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

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

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

сейчас у меня на работе права построены на таком объекте.
   Злопчинский
 
9 - 15.03.20 - 15:42
(8) "делаем элемент справочника в нем тч тип+значение"
.
а как если для одного надо "контрагент+документ" (2 реквизита), а для другого "контр+контр+документ" - 3 реквизита и т.д.? сколько реквизитов в элементе справочника надо/как?
   vi0
 
10 - 15.03.20 - 16:38
(8) 10 лет назад рауз уже был
   vi0
 
11 - 15.03.20 - 16:41
я где то читал что подобная технология была в советское время и даже имела какое то название конкретное, сейчас не могу в сети найти
   vde69
 
12 - 15.03.20 - 17:14
(9) в справочнике табличная часть, сколько надо аналитик столько и надо
   vi0
 
13 - 15.03.20 - 17:21
(8) у тебя только требования по функционалу были, по производительности не было?
   ДенисЧ
 
14 - 15.03.20 - 17:28
(8) @ когда еще РАУЗ-а не было и в помине :) примерно 10 лет назад@

10 лет назад РАУЗ был в само расцвете ))
   vde69
 
15 - 15.03.20 - 17:32
(13) у меня требования были к скорости чтения, то есть запись медленная а чтение быстрое.
   vde69
 
16 - 15.03.20 - 17:34
(14) (10) это были 2006...2007 года
   vde69
 
17 - 15.03.20 - 17:35
(16) + а рауз появился 2008...2009
   ДенисЧ
 
18 - 15.03.20 - 17:40
(16) 2006 год был 15 лет назад ))
   vi0
 
19 - 15.03.20 - 17:52
(15) а разве не наоборот?
чтение ухудшается за счет соединений нескольких таблиц, в твоем случае из три: основная, ключ, ТЧ ключа
а запись наоборот быстрее т.к. часть ключей уже есть
   vde69
 
20 - 15.03.20 - 17:52
(18) ну я примерно сказал 10 лет, потом глянул даты работы выходит 2006 год, это я в банке документооборот делал, тогда только вышел ДО 1.0, мы его купили, но он не пошел у нас, пришлось переписывать почти все...
   vde69
 
21 - 15.03.20 - 17:57
(19) при чтении у тебя уже известен элемент справочника (он как ссылка записывается куда надо, например в документы или в движения), а потом простой джойн по одной ссылке и все...

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

я тогда использовал текстовый ключ который генерировался из всей аналитики ТЧ в виде мд5 хеша и уже по хешу искал, там были нюансы с сортировками и т.д. и схема вышла "хрен разберешь" но она работала. Сейчас я немного по другому делаю, и теперь и более менее понятно и быстро (за счет некой денормализации)
   Aleksey
 
22 - 15.03.20 - 18:03
как бы справочник партия из лохиатого ТиС имеет такую же структуру и назначение
   Сияющий в темноте
 
23 - 15.03.20 - 18:05
(21)подобный алгоритм используется в nosql базах для создания сложных индексов,когда вместо длинного индекса строится индекс по хэш функции,а уже остальное ищется по найденным по хэшу значениям.
   Сияющий в темноте
 
24 - 15.03.20 - 18:12
(11) не в советские времена,а в теории баз данных
создание связей много на много при помощи синтетического ключа.
есть характеристики (номенклатура,партия и т.п.)и есть движения(то есть документы)между ними связь много на много,и вот для приведения этой связи в две один на много создается искуственная сущность,которая и есть ключ аналитики.
   vi0
 
25 - 15.03.20 - 18:21
(24) сущность называется суррогатный ключ
   Злопчинский
 
26 - 15.03.20 - 19:50
(12) табличная часть к чему? к элементу справочника? и для каждого элемента в справочнике можно задать произвольное количество запсией тип-значение?
   vde69
 
27 - 15.03.20 - 20:48
(26) да.

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

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

далее этот элемет справочника использовался в виде ссылки
   Сияющий в темноте
 
28 - 15.03.20 - 23:00
С табличной частью можно не морочиться,а всего два поля хэш и строка неограниченной длины.
запросамив базе все равно эти ключи сложно собрать,а в коде строки практичнее.
   vi0
 
29 - 16.03.20 - 07:05
(24) если не ошибаюсь, это движение в сторону четвертой нормальной формы
   dmpl
 
30 - 16.03.20 - 09:15
(3) А еще защита от криворуких программистов, которые не умеют пользоваться ВЫРАЗИТЬ :)
 
 Рекламное место пустует
   dmpl
 
31 - 16.03.20 - 09:16
А вот тому, кто убрал код их ключей аналитики руки бы вырвать надо...
   ptiz
 
32 - 16.03.20 - 09:25
Знаю фирму, где в самописке извращались: вместо двух измерений Товар и Характеристика - сделали одно типа "ключа". Наелись с тормозами, потом переделали нормально.
   vi0
 
33 - 16.03.20 - 09:59
(32) зачем сделали так? На каких операциях тормозило?
   ptiz
 
34 - 16.03.20 - 10:00
(33) Точно не могу сказать, просто сам факт помню.
   vi0
 
35 - 16.03.20 - 10:07
(34) может неправильно использовали
   vi0
 
36 - 16.03.20 - 12:56
кто нибудь делал подобное для оптимизации?
   celentano
 
37 - 19.03.20 - 19:19
(36) Мы использовали аналогичный подход на 1С:УХ (1.3) что бы в рамках бюджета можно было использовать более 5 аналитик на бюджетных классификаторах с минимально возможным изменением типовой архитектуры. Т.е. в первую очередь преследовали именно функциональные задачи. Дополнительно получили технологический плюс в части экономии места в базе и как следствие регламентные операции (обслуживание индексов, бэкапы и пр.) выполнялись быстрее, чем если бы мы добавили в регистр хранения аналитик еще 8 измерений, что бы можно было в них хранить необходимые аналитики. Аналогично со скоростью записи данных в регистр, в большинстве случаев чем меньше в таблице полей, тем скорость записи быстрее, а новые комбинации аналитик планирования появлялись не так активно, как использовались существующие. У нашего заказчика были достаточно увесистые бюджеты с глубокой детализацией планирования, про фактические бюджеты вообще молчу.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.