У Радченко в профразработке в главе про быстродействие было про индексы и регистр бухгалтерии. Сейчас под рукой нету
Вроде как больше 16 полей в индекс не лезет. А одно субконто - это три поля плюс еще периоды и какие-то еще служебные поля.
Про размер составного индекса в т.ч. на курсе по платформе слышал от Белоусова в УЦ №1.
Вроде ж в 8-ке учли ошибки 7-ки и на общую производительность увеличение количества субконто на единичных счетах повлиять не должно?
Ограничение на стороне ms sql у него ограничение на индекс в 16 полей. Пятое и последующее субконто не будет попадать в индекс. Из за чего отбор будет по первым четырем субконто, а по пятому вернёт все записи и будет искать перебором.
(8) А! Ну, это проблемы работы с доп-субконто по этим конкретным счетам. Это не страшно. В 7-ке просто было, что добавление новых субконто автоматически вело к разбуханию итогов по всем счетам. А в 8-ке итоги по разному количеству субконто раздельно хранятся.
(9)Я думаю еще проблемы с отчетами (стандартными и регламентированными). Там все запросы заточены именно под три субконто. В 7-ке так точно приходилось допиливать всю стандартную отчетность конфигурации.
Ограничение на стороне ms sql у него ограничение на индекс в 16 полей. Пятое и последующее субконто не будет попадать в индекс. Из за чего отбор будет по первым четырем субконто, а по пятому вернёт все записи и будет искать перебором.
Эту фигню я в проф-разработке читал. А самая типа жесть - еще и примитивных типов в субконто насыпать. Тогда типа страйк.
(1) Возможно из-за того, что если в РБ больше 15 измерений, то часть из них в индексе заменится на хеш по которому seek не будет работать, что приведет к резкому падению производительности.