День добрый.
Ситуация:
Есть остаточный регистр, ведется с начала веков, 1 ресурс, несколько измерений.
Движения в него делаются почти всеми товарными документами, остатки по нем не контролируются.
Проблема:
Необходимо добавить в него 2 ресурс, причем в большинстве своем (почти для 95% товаров), он будет равен 0.

Пути решения:
1) Добавить ресурс.
2) Запилить практически идентичный регистр остатков.

(0)[Запилить практически идентичный регистр остатков.]
без вариантов

общая концепция типовых - оптимизация чтения (а не записи)

по этому если у тебя по смыслу запросы ресуров 1 и 2 выполняются вместе (например при проведении) то добавить ресурс, если не - запилить регистр

(1) СОгласен.

сувалка где ?

(2) При проведении нет запросов к этому регистру.

Этот регистр только для отчетов, которые практически некритичны по времени.

Мне важно проводить документы быстро.

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

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

ну и кстати прикинь может в будующем менятся состав измерений?

(5) если на первом месте - быстрота проведения, тогда второй ресурс в том же регистре вроде поскорее должно быть, при условии, что первый ресурс заполняется в любом случае.
и при условии, что заполнение второго ресурса можно добавить в ту же процедуру. но если код типовой и нежелательно его изменять, то подписка, а тогда уж проще отдельный регистр.

В 96 процентов случаев в новый регистр ничего писаться не будет.

Запись "ничего" в регистр - насколько ресурсоемко?

уже 96... так скоро и до 146 дойдёшь :-)

(10) Не рассматривал это тему.

С учетом того, что это УПП и у него есть УдалитьДвижения()

(10) зачем писать ничего? если Ничего Тогда продолжить; КонецЕсли;

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

(0) я - за запилить. Уже хотя бы на реструктуризации таблиц физической и итогов с пересчетами выиграешь.

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

+(15)

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

(18) КоличествоОсобое

(19) а чо не Количество2?..

(20) Хитрый план, шоб враги не узнали.

(21) называть надо правильно!

КоличествоВЧерную или СуммаУкраденая или СуммаВзяток Ж)

(22) Ну или как-то так.

Данные будут однозначно компактнее если

Идентичный вопрос - надо разместить КоличествоОсобое в ТЧ Товары.

При это оно, это количество будет не равно 0 в 4% документов.

Притом это Количество будет для многих товарных документов.

1) Разместить в ТЧ Товары
2) Разместить в отдельной ТЧ.
3) Разместить в РС, во структуре аналогичном ТЧ Товары (измерения Объект, НомерСтроки, Ресурс - Номенклатура, КоличествоОсобое), только объект будет не одна ссылка, а составная.

1) Разместить в ТЧ Товары КАЖДОГО документа
2) Разместить в отдельной ТЧ. для КАЖДОГО документа.

3 вариант для меня идеален, в плане модификации и обновления на новые типовые релизы.

Если просто добавить новую колонку - регистр распухнет одинаково независимо от того, заполнена колонка или нет.

(29) Я знаю.

(28) а вариант 2 чем не идеален?

(29) Это для измерения актуально, добавление ресурса не приведет к увеличению строк регистра ("разбуханию" в моем представлении), только к незначительному увеличению объема (если тип ресурса число 4 байта * количество строк).

(0) Я думаю правильнее "Запилить" - второй вариант

(33) Создавать дохрена табличек в SQL, со своими индексами, которые им даст система. При это почти наверняка в 90% из них будет от силы 1000 записей.

(25) А для чего добавлять колонку, для отчетов?

(37) Чтобы по ней движение в регистр накопления делать.

(25) Тогда я бы просто разместил в ТЧ - на производительности это не скажется.

+ (40) Только проверить сколько пересчет таблицы будет длиться

(40) Это десятки мильенов строк в базах, которые ведутся с начала веков.

(42) Если мы говорим про ТЧ в документе, она получается для каждого документа по кластерному ключу очень быстро практически независимо от количества строк.
формула приращения таблицы 4байта * десятки млн. строк - то есть где-то максимум увеличиться на десятки мегабайт.
Если не для чего другого не надо регистр сведений, то не стоит усложнять.

(0) а что за ресурс? остатки по нему не требуются? оборотный регистр с нужным измерением... писАть в документах только там где надо - самое быстрое в проведении, ну, и получении данных для отчёта собстна %)

(25) отдельная ТЧ, связанныая с основной ТЧ. На форме отображать количество особое в ТП с основной ТЧ. И компактно и ползователям прозрачно. ТОлько для этого надо, чтобы в основной ТЧ был какой-то ключ

(45) хотя это конечно туповые обновления потом пригорюнит

(44) Остатки нужны.

(45) Не надо нам такого юзабилити.

РС прям идеально вписывается.
В ПриОткрытии/ПриСозданииНаСервере вызываются наша общая процедура, которая достраивает интерфейс. Там и будет ОсобаяКнопка, по нажатию на которой откроется форма. После заполнения основной части документа, для некоторых товарных позиций надо рассчитать вдумчиво КоличествоОсобое.

(10) запись ничего раньше блокировала весь регистр.

(49) Это если остатки контролировать и писать запрос ДляИзменения.

(49) Я пытаюсь учесть все на берегу :-)

Думаю, сделал бы как проще - добавить ресурс и колоку в существующие ТЧ

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

(52) и пофигу, что реструктуризация будет все майские праздники идти, да?

(54) Вот наши клиенты порадуются.

(47) ыть :( а что за 2-й ресурс?? и 1-й для чего? Чем они отличаются? Данные по 1-му и 2-му ресурсам пользователем выбираются как правило вместе? Или чаще каждый в своём отдельном отчёте?
Если они не совмесны, то скорее всего:

(55) ога, внесете в список фич нового релиза: "Внедрена функция отдохнуть на майские"

(54) Если объем регистра таков, что [реструктуризация будет все майские праздники идти] тогда, что обсуждать? Вариант только один тогда остается.

(50) не обязательно. но я не знаю актуально ли это сейчас для 8.2

(58) вариатнов больше двух, если чо

(59) актуально.

(56) КоличествоОсобое зависит от Количества, но нелинейно. Приходится его заносить для каждого документа.

(53) да. я именно это и имел ввиду.
(54) этого можно избежать, если дело только в этом.

(60) ога, например поставить 8.3 и провести реструктуризацию в фоновом режиме. Да масса вариантов, главное чтобы [клиенты порадуются]

(64) отличный план. Просто превосходный.

(64) есть способы проще

(65) не льсти себе подойди поближе :) это сарказм.
(66) + 1