Всем доброго дня!

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

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

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

Вот, скажите, хорошо это или плохо так делать (строку в измерение)? Если плохо, то какая альтернатива может быть?

Не взлетит

А как ты будешь искать когда например значение будет только первое и третье? По ПОДОБНО? по строковому полю длиной 200 символов?

Ну, физически взлетит же, 1с даст добавить измерение такой длины? Индексы нормально не будут работать?

(3) Ты сделай, потом нам расскажи, что пошло не так

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

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

(4) Добавить измерение длинной в 200 строк 1с дало.

Альтернативы? Завести 5 измерений типа ЛюбаяСсылка?

(0) Ну вообще гуид - это 16 байт.
Но в целом да, такое реально, но длинный индекс - это не очень хорошо (строка 200 символов будет 400 байт в UTF-8).
В любом случае, если точную строку знаешь при поиске, работать будет.

(8) ок, можно сократить гуид до 16 символов (1с возвращает 36, отбрасываем "-", получается 32), тогда уже строка меньше.

Я понимаю, что работать будет )) Главное, чтобы быстро.

а порядок важен?
в базе может быть записан набор (Консервы;Спички) а на входе будут искать (Спички;Консервы)

(9) Что такое быстро?
Будет использоваться индекс, а значит, будет на порядки быстрее, чем фуллсканом.
Возможные альтернативы - использование такие сущностей, как "КлючАналитикиБлаБлаБла"

Можно еще генерить элементы с ключами в справочнике, а в РС держать одну ссылку на справочник.
Но тут тоже накладные расходы, надо будет найти нужный элемент в справочнике, а потом поиск по РС.

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

(13) Может повторяться, но в совокупности с другими ключами.
Но как тогда справочник построить? 5 реквизитов в нем ЛюбаяСсылка и поиск по ним? Тоже криво как-то, как мне кажется.
Или в его наименование писать индексную строку, как хотел выше?

(10) Порядок важен, но он будет известен перед поиском.

(14) Не влезет она в наименование.
Ответ про "Может повторяться, но в совокупности с другими ключами" - не понял

(15) точнее порядок как таковой не важен, но он будет фиксирован и известен. Важна уникальность ключей.

(14) 5 реквизитов в справочнике - плохая идея, 1С не даст составной индекс залепить по ним. Тут нужен РС и измерения тогда, который будет хранить ссылку на справочник.
Ну или строку отдельным реквизитом в справочнике.

(26) имел в виду, что есть измерение Спички, оно может быть в разных записях:
Спички,Консервы,Нож
Паровоз,Спички,Бумага,Ручка
Спички,Зажигалка

(19) быстро это не будет работать. С (0) - тем более

(18) А по фиксированной строке реквизита справочника скуль построит индекс? Думаю, должен.

(19) Я спрашивал про селективность ключа, а не части ключа.
Паровоз,Спички,Бумага,Ручка часто повторяется?

(21) Поставишь индексировать - построит

(22) только 1 раз в периоде
забыл написать, что РС периодический (по дням) и подчиненный.

может просто справочник с наименованием?

(25) наименование макс 150 символов

(20)
Быстро и медленно - не очень внятные понятия.
Наличие индекса по строке 200 в 400 байт, конечно, проигрывает в скорости наличию индекса в 16 байт, но это значительно быстрее скана, очень значительно быстрее.

Цель-то какая? Найти все комплекты, в которые входят все комплектующие из заданного списка?

(24) Делай через справочник с реквизитом. У справочника убери длину наименования и кода, чтобы лишние индексы не создавались. Делай реквизит строка(200) с "Индексировать".

Если нужно как-то работать с ключами, т.е. искать по измерению конкретному и т.д., то РС с измерениями и ссылкой на справочник.

(28) Не совсем. Таблица будет содержать тарифы разных поставщиков услуг, у каждого поставщика свой набор измерений на разные услуги, например:
у одного для доставки: Откуда, Куда, Тип груза
для страхования: Тип груза, Стоимость (по шкале)

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

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

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

Как-то так.

Составной индекс по измерениям будет 5*(16(TRef)+16(RRef)) = 5*32 = 160 байт, т.е. очень приближенно поиск по строке 200 будет в 2.5 раза дольше выполняться, чем если измерения используешь. Но по факту больше времени уйдет на построение плана запроса, реальная разница будет проявляться при многократных повторениях при закэшированном плане запроса.

Про скорость: не будет за раз как-то расчета сразу большого объема данных. По сути юзер заводит документ там в ТЧ несколько строк с услугами, где-то до 5. По сути до 5 вызовов за раз. Пусть расчет пройдет даже 0.5 сек, приемлемо.

А вот если несколько сек расчет плюс еще база распухнет от индексов -- не хотелось бы.

(0) Несколько регистров сделать и не извращаться.

(34) А чем они будут отличаться между собой? Поставщики могут меняться, у каждого своя тарифная сетка.

уже было про характеристики?

в смысле про справочник характеристик, как в УТ? где несколько "значений" или "измерений" упаковывают в один элемент справочника

(36) Нет! Внимательно слушаю ))

А то в голову лезут всякие извращенские мысли по хешированию индексной строки или переводу ее в число и запись этого в измерения ))

(37) Ну по сути, это наподобие использовать дополнительный справочник и хранить его ссылку в РС, как предлагали выше.

(0) хочет рауз?

(0) Почитай про план видов характеристик

(32) Вот тебе информация к размышлению:
У меня есть база, в ней есть справочник, в котором 20 749 430 записей.
У справочника есть наименование длиной 25.
После freeproccache, т.е. без готового плана запроса, результаты поиска такие:
Поиск по наименованию длится 0.002 сек  (строка индекса 50 байт+ Rref тоже в индексе, т.е. 66 байт)
Поиск по гуиду - 0.001 сек

Если выбирать поле, не покрываемое индексом то:
Поиск по наименованию длится 0.003 сек (добавляется key lookup)
Поиск по гуиду также 0.001 сек (т.к. кластерный индекс покрывает все поля, key lookup отсутствует)

а скан сколько длится по справочнику?

(43) Несколько минут - размер таблицы там 120 гигабайт, фуллсканы не допускаются - кэша не хватает

(30) мракобесие какое-то. Я ни хрена не понял.

(45) Нет, реальная задача ))
Представь, что есть несколько поставщиков транспортных услуг, у них таблица услуг по нескольким аналитикам.
Например, для одного авиа перевозчика по строкам будет откуда-куда (2 измерения), по колонке будет тип груза + шкала веса.  
А у автоперевозчика прайс немного по другим критериям.
Плюс у одного, например, доп измерение в прайсе когда доставка в выходной день.
Вот и хранить эти разнородные таблицы в регистре и находить стоимость услуг по совокупности измерений.
Каждое измерение может быть привязано к разным видам справочников или перечислений.

Не создавать же каждому поставщику свой РС.

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

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

А забивать стоимость кто и как будет

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

хм, ну тут 2 варианта. Либо типа рауза делать - эту систему можно глянуть в любом упп или в ут 11. Либо сделать кривее, проще, но не столь гибко - в регистре 5 (или сколько максимум будет у вас) Измерений. Столько же ресурсов. Измерения ссылаются на элемент справочника или другой регистр сведений, или план видов характеристик, в котором хранятся все ваши возможные результаты - если элемент не находится перед/при записи, то он туда добавляется.
Получается недо-рауз.

Строковые я бы не советовал делать. В крайнем случае любая ссылка.

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

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

(51) В чем у тебя проблемы со строками? Чем насолили?

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

Без перелопачивания регистра

В общем решил я извратиться так:
1. Индексную строку по динамическим измерениям формировать комбинацией измерений, но в регистре ее не хранить
2. В регистре хранить хэш функцию (число) этой строки, ну и еще пара служебных измерений фиксированного типа (ссылка на спр тарифов)
3. При поиске формировать индексную строку, брать ее хэш и искать запись.
Должно работать по идее.

Вообще, какие строки ???

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

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

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

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

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

Как бы всё.

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