добрый день!
1С Предприятие 8.3, конфигурация УТ 10.3

Есть регистр накопления - остатки, его измерения:
1. Контрагент
2. Склад
3. Номенклатура
4. ДокументПартии
--------------
нужна максимальная производительность, все поля Не индексированы.
по умолчанию в Таблице Остатков в SQL Server генерируется только один кластерный индекс.
кластерный индекс - это Период + Измерение1 + ... + ИзмерениеN.
в запросах на получение остатков отбор измерений задается в порядке следования так, как он задан в конфигураторе (кластерный индекс)

т.е. запрос выглядит следующим образом
ВЫБРАТЬ
    Остатки.ДокументПартии,
    Остатки.КоличествоОстаток,
ИЗ
    РегистрНакопления.ПартииТоваров.Остатки(&Дата, Контрагент = &Контрагент И Склад = &Склад И Номенклатура В (&Номенклатура)) КАК Остатки

заполнено только одно измерение 1.Контрагент либо измерение 2.Склад, сразу два этих измерения заполненными быть не могут.
вопрос.
если объединить эти два измерения в одно, увеличит ли это скорость получения остатков? какие плюсы, и минусы?

измерение Контрагент имеет тип 'СправочникСсылка.Контрагенты'
измерение Склад имеет тип 'СправочникСсылка.Склады'

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

с точки зрения быстродействия, как будет лучше объединить эти два измерения в одно, или оставить разделенными?
желательно развернутый ответ.
заранее спасибо!

Индекс-то есть, а его обслуживание регулярно делается?

каким образом ты собираешься объединять два измерения в одно?

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

и это... большой объем данных - это сколько?

(2) это новый регистр. сейчас идет ввод в эксплуатацию
я понимаю что важно, но сейчас хочу сразу сделать систему такой, чтобы она работала максимально быстро...
т.к. объем данных очень большой :)
контрагенты, у которых хранится наш товар 200 шт.
наши склады, 50 шт.
номенклатура, по которой мы торгуем, списываем со склада и обмениваемся с контрагентами, 20 000 шт.
документов, образующих новые партии, в месяц 10 000 и больше

(6) Копейки.... купите нормальныйсервер

просто добавить памяти и загнать ка можно больший кусок базы в буферпул

(3) сделать измерение составного типа
'СправочникСсылка.Контрагенты'
'СправочникСсылка.Склады'

(6) пфф! и всё?..

(9) ни в коем случае этого не делай. Составной тип - зло кипучее для производительности.

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

(12) строиться индекс будет, но отборы по этому полю будут транслированы в злоебучий "when then else", при одном взгляде на который оптимизатор устало скажет: "а, идите в допу - тэйбл скан!"

(7) спасибо, но пока вроде бы на стадии внедрения всё работает быстро, расчет себестоимости за 1 месяц по всему холдингу (200 контрагентов) делается в пределах суток.
но просто озадачился быстродействием, и хочу понять, что быстрее в моем случае, объединить 2 измерения и сделать одно составного типа, или оставить как есть :)

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

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

(14) сколько записей в регистре твоем?

(13) спасибо вам большое! теперь понял. с вами согласен.

(16) эмм... пример покажешь?

Регистр.ИзмерениеСкладКонтрагент ССЫЛКА Справочник.Склады и Регистр.ИзмерениеСкладКонтрагент=&Склад

(20) да ладно! И с "В" поможет, и с отбором по реквизитам?

хотя с отобором по реквизитам кластер при любом раскладе не будет использоваться

(20) С "В" не пробовал. Отбор по реквизитам делайте потом, когда Остатки во временную поместите.

(17) >>сколько записей в регистре твоем?

ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ РегистрНакопления.ПартииТоваров
за 3 месяца - 20 млн.

на два регистра разнести?
по типу свои остатки и остатки коммисионеров

(25) кстати да, очень хорошая идея. надо подумать. спасибо!

(24) Плохо придется базе под реальной нагрузкой. По партиям же и себестоимость считается.. Очень скоро (после года эксплуатации) себестоимость будет за месяц считаться несколько суток. Может быть, вытащить детализацию в какую-то внешнюю таблицу, а в самом регистре хранить итоговые значения? например, за 3 дня или неделю. А детализацию до операции - во внешней таблице, и обращаться к ней только при необходимости..

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

при списании делается запрос на получении остатков в разрезе Документов партий, и эти партии списываются по FIFO

ВЫБРАТЬ
    Остатки.ДокументПартии,
    Остатки.КоличествоОстаток,
    Остатки.СтоимостьОстаток,
ИЗ
    РегистрНакопления.ПартииТоваров.Остатки(&Дата, Контрагент = &Контрагент И Склад = &Склад И Номенклатура В (&Номенклатура)) КАК Остатки

(27) >>Может быть, вытащить детализацию в какую-то внешнюю таблицу, а в самом регистре хранить итоговые значения?

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

(27) после расчета себестоимости по каждой списанной (проданной) номенклатуре, эти данные выгружаются в Бухгалтерию,  и там они уже свернуты по документу одной строчкой.
было продано Иванову товара на сумму 100 тыс. руб., себестоимость проданного товара 70 тыс. руб.