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


1С:Предприятие :: 1С:Предприятие 8 общая

Строковое измерение регистра сведений

Строковое измерение регистра сведений
Я
   Ivan093
 
25.10.16 - 14:31
Всем доброго дня!

Прошу совета, как лучше сделать.
Задача такая: хранить в РС таблицы с разным количеством измерений в строках (по строкам таблицы несколько измерений), измерение колонки всегда одно. В качестве измерений может быть любая ссылка на справочник или перечисление. Количество измерений не фиксировано для разных наборов записей, т.е. один документ записал в РС записи, где 2 измерений, другой где 5. Измерений будет до 5 где-то, не более.

Мысль такая: писать в измерение регистра фиксированную строку, а-ля индекс, для справочников брать гуид, для перечисления его имя.
Т.е. генерировать строку, например, "<ГуидИзмерения1>,<ГуидИзмерени2>,...<ГуидИзмерения5>". Если гуид -- это 36 символов, то строка уложится в 200 символов.

Цель: чтобы быстро работал поиск нужной строки по набору измерений.

Вот, скажите, хорошо это или плохо так делать (строку в измерение)? Если плохо, то какая альтернатива может быть?
 
 
   Волшебник
 
Модератор
1 - 25.10.16 - 14:34
Не взлетит
   Живой Ископаемый
2 - 25.10.16 - 14:36
А как ты будешь искать когда например значение будет только первое и третье? По ПОДОБНО? по строковому полю длиной 200 символов?
   Ivan093
 
3 - 25.10.16 - 14:36
Ну, физически взлетит же, 1с даст добавить измерение такой длины? Индексы нормально не будут работать?
   Волшебник
 
Модератор
4 - 25.10.16 - 14:36
(3) Ты сделай, потом нам расскажи, что пошло не так
   Ivan093
 
5 - 25.10.16 - 14:37
(2) такого не будет. Надо искать по фиксированному набору измерений, которое заранее известно, но может в одном случае быть 2, в другом 4. Но перед поиском оно известно и можно собрать индексную строку и по ней найти запись.
   mehfk
 
6 - 25.10.16 - 14:39
(0) Будет медленно и громоздко, а автора будет мучить постоянная икота.
   Ivan093
 
7 - 25.10.16 - 14:40
(4) Добавить измерение длинной в 200 строк 1с дало.

Альтернативы? Завести 5 измерений типа ЛюбаяСсылка?
   MrStomak
 
8 - 25.10.16 - 14:41
(0) Ну вообще гуид - это 16 байт.
Но в целом да, такое реально, но длинный индекс - это не очень хорошо (строка 200 символов будет 400 байт в UTF-8).
В любом случае, если точную строку знаешь при поиске, работать будет.
   Ivan093
 
9 - 25.10.16 - 14:43
(8) ок, можно сократить гуид до 16 символов (1с возвращает 36, отбрасываем "-", получается 32), тогда уже строка меньше.

Я понимаю, что работать будет )) Главное, чтобы быстро.
   Naf_kultura
 
10 - 25.10.16 - 14:45
а порядок важен?
в базе может быть записан набор (Консервы;Спички) а на входе будут искать (Спички;Консервы)
 
 Рекламное место пустует
   MrStomak
 
11 - 25.10.16 - 14:45
(9) Что такое быстро?
Будет использоваться индекс, а значит, будет на порядки быстрее, чем фуллсканом.
Возможные альтернативы - использование такие сущностей, как "КлючАналитикиБлаБлаБла"
   Ivan093
 
12 - 25.10.16 - 14:45
Можно еще генерить элементы с ключами в справочнике, а в РС держать одну ссылку на справочник.
Но тут тоже накладные расходы, надо будет найти нужный элемент в справочнике, а потом поиск по РС.
   MrStomak
 
13 - 25.10.16 - 14:46
(12) имеет смысл, если один ключ в регистре будет много раз повторяться
   Ivan093
 
14 - 25.10.16 - 14:48
(13) Может повторяться, но в совокупности с другими ключами.
Но как тогда справочник построить? 5 реквизитов в нем ЛюбаяСсылка и поиск по ним? Тоже криво как-то, как мне кажется.
Или в его наименование писать индексную строку, как хотел выше?
   Ivan093
 
15 - 25.10.16 - 14:49
(10) Порядок важен, но он будет известен перед поиском.
   MrStomak
 
16 - 25.10.16 - 14:50
(14) Не влезет она в наименование.
Ответ про "Может повторяться, но в совокупности с другими ключами" - не понял
   Ivan093
 
17 - 25.10.16 - 14:50
(15) точнее порядок как таковой не важен, но он будет фиксирован и известен. Важна уникальность ключей.
   MrStomak
 
18 - 25.10.16 - 14:52
(14) 5 реквизитов в справочнике - плохая идея, 1С не даст составной индекс залепить по ним. Тут нужен РС и измерения тогда, который будет хранить ссылку на справочник.
Ну или строку отдельным реквизитом в справочнике.
   Ivan093
 
19 - 25.10.16 - 14:52
(26) имел в виду, что есть измерение Спички, оно может быть в разных записях:
Спички,Консервы,Нож
Паровоз,Спички,Бумага,Ручка
Спички,Зажигалка
   Лефмихалыч
 
20 - 25.10.16 - 14:53
(19) быстро это не будет работать. С (0) - тем более
   Ivan093
 
21 - 25.10.16 - 14:54
(18) А по фиксированной строке реквизита справочника скуль построит индекс? Думаю, должен.
   MrStomak
 
22 - 25.10.16 - 14:54
(19) Я спрашивал про селективность ключа, а не части ключа.
Паровоз,Спички,Бумага,Ручка часто повторяется?
   MrStomak
 
23 - 25.10.16 - 14:54
(21) Поставишь индексировать - построит
   Ivan093
 
24 - 25.10.16 - 14:55
(22) только 1 раз в периоде
забыл написать, что РС периодический (по дням) и подчиненный.
   Мойдодыр
 
25 - 25.10.16 - 14:55
может просто справочник с наименованием?
   Ivan093
 
26 - 25.10.16 - 14:56
(25) наименование макс 150 символов
   MrStomak
 
27 - 25.10.16 - 14:57
(20)
Быстро и медленно - не очень внятные понятия.
Наличие индекса по строке 200 в 400 байт, конечно, проигрывает в скорости наличию индекса в 16 байт, но это значительно быстрее скана, очень значительно быстрее.
   Лефмихалыч
 
28 - 25.10.16 - 14:58
Цель-то какая? Найти все комплекты, в которые входят все комплектующие из заданного списка?
   MrStomak
 
29 - 25.10.16 - 15:00
(24) Делай через справочник с реквизитом. У справочника убери длину наименования и кода, чтобы лишние индексы не создавались. Делай реквизит строка(200) с "Индексировать".

Если нужно как-то работать с ключами, т.е. искать по измерению конкретному и т.д., то РС с измерениями и ссылкой на справочник.
   Ivan093
 
30 - 25.10.16 - 15:05
(28) Не совсем. Таблица будет содержать тарифы разных поставщиков услуг, у каждого поставщика свой набор измерений на разные услуги, например:
у одного для доставки: Откуда, Куда, Тип груза
для страхования: Тип груза, Стоимость (по шкале)

У другого для его услуг:
у одного для доставки: Откуда, Куда, Тип груза, Срочность
для страхования: Стоимость (по шкале)

Каждая запись привязана к ссылке на справочник тарифов.

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

Как-то так.
   MrStomak
 
31 - 25.10.16 - 15:05
Составной индекс по измерениям будет 5*(16(TRef)+16(RRef)) = 5*32 = 160 байт, т.е. очень приближенно поиск по строке 200 будет в 2.5 раза дольше выполняться, чем если измерения используешь. Но по факту больше времени уйдет на построение плана запроса, реальная разница будет проявляться при многократных повторениях при закэшированном плане запроса.
   Ivan093
 
32 - 25.10.16 - 15:08
Про скорость: не будет за раз как-то расчета сразу большого объема данных. По сути юзер заводит документ там в ТЧ несколько строк с услугами, где-то до 5. По сути до 5 вызовов за раз. Пусть расчет пройдет даже 0.5 сек, приемлемо.
   Ivan093
 
33 - 25.10.16 - 15:09
А вот если несколько сек расчет плюс еще база распухнет от индексов -- не хотелось бы.
 
 
   ptiz
 
34 - 25.10.16 - 15:17
(0) Несколько регистров сделать и не извращаться.
   Ivan093
 
35 - 25.10.16 - 15:21
(34) А чем они будут отличаться между собой? Поставщики могут меняться, у каждого своя тарифная сетка.
   Fragster
 
36 - 25.10.16 - 15:24
уже было про характеристики?
   Fragster
 
37 - 25.10.16 - 15:26
в смысле про справочник характеристик, как в УТ? где несколько "значений" или "измерений" упаковывают в один элемент справочника
   Ivan093
 
38 - 25.10.16 - 15:27
(36) Нет! Внимательно слушаю ))

А то в голову лезут всякие извращенские мысли по хешированию индексной строки или переводу ее в число и запись этого в измерения ))
   Ivan093
 
39 - 25.10.16 - 15:29
(37) Ну по сути, это наподобие использовать дополнительный справочник и хранить его ссылку в РС, как предлагали выше.
   newbling
 
40 - 25.10.16 - 15:36
(0) хочет рауз?
   arsik
 
41 - 25.10.16 - 15:40
(0) Почитай про план видов характеристик
   MrStomak
 
42 - 25.10.16 - 15:44
(32) Вот тебе информация к размышлению:
У меня есть база, в ней есть справочник, в котором 20 749 430 записей.
У справочника есть наименование длиной 25.
После freeproccache, т.е. без готового плана запроса, результаты поиска такие:
Поиск по наименованию длится 0.002 сек  (строка индекса 50 байт+ Rref тоже в индексе, т.е. 66 байт)
Поиск по гуиду - 0.001 сек 

Если выбирать поле, не покрываемое индексом то:
Поиск по наименованию длится 0.003 сек (добавляется key lookup)
Поиск по гуиду также 0.001 сек (т.к. кластерный индекс покрывает все поля, key lookup отсутствует)
   Мойдодыр
 
43 - 25.10.16 - 15:46
а скан сколько длится по справочнику?
   MrStomak
 
44 - 25.10.16 - 15:51
(43) Несколько минут - размер таблицы там 120 гигабайт, фуллсканы не допускаются - кэша не хватает
   Лефмихалыч
 
45 - 25.10.16 - 15:51
(30) мракобесие какое-то. Я ни хрена не понял.
   Ivan093
 
46 - 25.10.16 - 16:09
(45) Нет, реальная задача ))
Представь, что есть несколько поставщиков транспортных услуг, у них таблица услуг по нескольким аналитикам.
Например, для одного авиа перевозчика по строкам будет откуда-куда (2 измерения), по колонке будет тип груза + шкала веса.  
А у автоперевозчика прайс немного по другим критериям.
Плюс у одного, например, доп измерение в прайсе когда доставка в выходной день.
Вот и хранить эти разнородные таблицы в регистре и находить стоимость услуг по совокупности измерений.
Каждое измерение может быть привязано к разным видам справочников или перечислений.

Не создавать же каждому поставщику свой РС.
   Ivan093
 
47 - 25.10.16 - 16:12
В документе Накладная есть услуга "Доставка" и есть договор. В договоре есть привязка к тарифу (по сути поставщику).
У каждого вида тарифа (справочник) жестко задан набор измерений-реквизитов шапки дока.
Из накладной берется набор этих реквизитов и по ним надо найти стоимость услуги.

Для разных накладных в зависимости от поставщика будет свой набор значений реквизитов для поиска. В этом и сложность.
   newbling
 
48 - 25.10.16 - 16:13
А забивать стоимость кто и как будет
   Ivan093
 
49 - 25.10.16 - 16:17
(48) Загрузка будет из экселя в док установки тарифов, чтобы сотрудникам удобно работать было, а док уже писать в регистр будет.
 
 Рекламное место пустует
   newbling
 
50 - 25.10.16 - 16:55
хм, ну тут 2 варианта. Либо типа рауза делать - эту систему можно глянуть в любом упп или в ут 11. Либо сделать кривее, проще, но не столь гибко - в регистре 5 (или сколько максимум будет у вас) Измерений. Столько же ресурсов. Измерения ссылаются на элемент справочника или другой регистр сведений, или план видов характеристик, в котором хранятся все ваши возможные результаты - если элемент не находится перед/при записи, то он туда добавляется.
Получается недо-рауз.
   newbling
 
51 - 25.10.16 - 16:57
Строковые я бы не советовал делать. В крайнем случае любая ссылка.
   newbling
 
52 - 25.10.16 - 17:00
Как там сравнивать...вот это уже будет финт ушами. Ведь порядок какой будет хрен его знает. Видимо, нужно будет делать 5 (или сколько у вас там) соединений в запросе чтоб достать все комбинации по контру...да, надо же ещё будет измерение контрагента добавить и ресурс суммы.
   newbling
 
53 - 25.10.16 - 17:02
а, хотя можно сделать деревом - там будут по записи собраны строками все его варианты. В общем, тут ещё надо подумать будет.
   MrStomak
 
54 - 25.10.16 - 17:02
(51) В чем у тебя проблемы со строками? Чем насолили?
   newbling
 
55 - 25.10.16 - 17:04
(54) В том, что при загрузке из экселя там может быть всякий хлам, который будет в таком виде и писаться в регистр. А если справочники, то их всегда можно сравнить и свернуть.
   newbling
 
56 - 25.10.16 - 17:04
Без перелопачивания регистра
   Ivan093
 
57 - 25.10.16 - 22:18
В общем решил я извратиться так:
1. Индексную строку по динамическим измерениям формировать комбинацией измерений, но в регистре ее не хранить
2. В регистре хранить хэш функцию (число) этой строки, ну и еще пара служебных измерений фиксированного типа (ссылка на спр тарифов)
3. При поиске формировать индексную строку, брать ее хэш и искать запись.
Должно работать по идее.
   Torquader
 
58 - 25.10.16 - 22:39
Вообще, какие строки ???

Есть справочник "партнёры" - это те, кто оказывает нам услуги.

Есть справочник "услуги" - это то, что нам оказываются партнёры. Справочник "Услуги" подчинённый справочнику "Партнёры".

Теперь мы хотим описать услугу - у каждой услуги есть параметры - создаём план видов характеристик "ПараметрыУслуги", где описываем все параметры наших услуг, а также типы значений наших параметров.

Теперь создаём справочник "Тарифы", он будет подчинённый справочнику "Услуги". Также для него будет создан регистр сведений "ПараметрыТарифа" с измерениями "Тариф","Параметр" и "ЗначениеПараметра".

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

Как бы всё.
   Ivan093
 
59 - 26.10.16 - 07:56
(58) Спасибо за совет. Решил пока делать интерфейсную часть, как дойдет дело до структуры хранения прайсов еще раз обмозгую, может действительно ваш вариант подойдет.
Но нормально ли работают индексы по полям ЛюбаяСсылка?


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