Есть документ 1, документ 2
документ 1 может включаться в таб часть документа 2
нужно подбирать ссылки на документ 1 в табчасть документа 2, условие - ссылка на документ 1 может быть только в табчасти одного документа 2
делать условие НЕ В (Выбрать ...) мне кажется будет тормозом по мере роста количества документов
подумал сделать регистр накопления(измерение - Документ 1, ресурс - Количество), провожу документ 1 пишу в РН 1, включил документ 1 в документ 2, провел - списал 1 из РН
таким образом могу для подбора использовать Остатки()
или есть вариант получше?
зы: документов 1 и 2 может быть до тысячи в месяц

Я так понимаю это не клюшки? Почему не используешь регистр сведений?

(0) критерий отбора поюзать?

(0) Таб.часть и РС - практически одно и то же для SQL. Включи индексирование в таб.части и проверочный запрос будет летать.

(0) какой-то лишний велосипед. можно придумать проще.

(1) это то же , что и табчасть
(3) критерий - как я его понимаю, как дополнительный индекс?
(4) даже при увеличении кол-ва документов по производительности будет быстрее, чем остатки РН?

(5) посоветуй

Если документ1 будет измерением, а Документ2 ресурсом, то просто не получится записать Документ2 в двух документах Документ1

(8) зачем пользователю лишняя проблема с записью?

(0) а в последующем отборе как будешь действовать, если 1 списал?
Друг перепроведение и они опять добавятся в РН?

(6) Пятница, туплю, думал, что ты РС хочешь :)
Остаточный РН - тоже красиво, но избыточно, поиск по индексированному полю и так мгновенный.

(10) Друг => Вдруг

смешный обьемы. 1 секунда на запрос

(0) остатки пухнуть будут, если неоперативно доки подбирать-закрывать в ноль

сделай у дока 1 реквизит статус.
И меняй его тупо при проведении документа 2.

в подборе выбирай тока документы без статуса

не надо использовать НЕ В (Выбрать ...)
Используй левое соединиени и Есть NULL

на инфо написали "Формируемый для критерия отбора индекс позволяет сделать это достаточно быстро, но если данных в выборке окажется очень много, то выборка не будет формироваться эффективно. Поэтому целесообразно создавать критерии отбора по данным, имеющим большой разброс значений, чтобы выборки получались не очень большие.  В противном случае теряется смысл такого отбора и снижается его эффективность"
думаю критерий тоже медленно будет
(13) время будет расти в прогрессии со временем
(15) это я отмел в первую очередь, документы могут быть в закрытом периоде, да и перепроведение не всегда хорошо

(10) не понял опасения, количество записей при перепроведении не меняется то
(11) попробую индексированное поле

(15) А как тогда коллизии разбирать?
Оба еще не провелись, но в отбор каждого уже добавились доки. Тут тогда надо при проведении еще и проверять, а не изменился ли статус. А если изменился то что, удалять? нехорошо это

>>это я отмел в первую очередь, документы могут быть в закрытом периоде, да и перепроведение не всегда хорошо

Никто не запрещает записывать документ без перепроведения

(18) Но ему же добавится 1 в РС и его можно будет выбрать в другой документ2.

(20) ладно, это противоречит моему мировосприятию ))

(21) да какой регистр сведений?

(23) Блин...не РС, РН)

(6)
1. в конфигурации создать "Критерий отбора" Документы1 в Документах2. (Общие-Критерии отбора)
2. Запросы делать к критерию отбора

(24) как добавится еще 1?
при каждом проведении документа 1 будет писаться приход(1)?

(19)РН тоже придется проверять при проведении на отрицательные остатки

(23) Ты перепроводишь док1. У них в РН появилось еще одно движение с +1. И он может попасть в док2

+26 будет всегда одна и таже запись с Приход(1)

(28)С чего бы добавилось еще одно движение?

(28) моя твоя не понимай
при любом проведении документа 1 будет всегда только 1 и все, никаких добавок

(29) Да, приход(1), потом расход(1), а смотришь ты по остаткам.

(32) да, где есть остатки

(33) тьфу...туплю...РН же...регистраторы и т.п.

(32) ага... приход+расход выходим в ноль и опять выбираем док1 без зазрения совести

(35)Он как раз с остатком выбирать собирается, а не без

Хороший вопрос был про закрытие регистра: все документы1 будут уложени в док2?

(36) так, да. Будет работать. Но стоит ли оно того

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

в (19) истину глаголит
В любом случае нужно будет еще при проведении проверку делать. Так что, возможно, вариант с РС не так уж и плох

(39) ты повторяешься

(37) вот это вопрос. По идее - да, те, которые не войдут должны быть удалены.

"(13) время будет расти в прогрессии со временем "

Отличный индикатор 1Спрограммиста.
Интересно, про какую прогрессию идет речь. Ну, допустим, арифметическая. Это верно для поиска не по индексу, для индексного поиска верна логарифмическая прогрессия:
https://ru.wikipedia.org/wiki/B%2B-дерево#.D0.92.D1.8B.D1.87.D0.B8.D1.81.D0.BB.D0.B8.D1.82.D0.B5.D0.BB.D1.8C.D0.BD.D0.B0.D1.8F.D1.81.D0.BB.D0.BE.D0.B6.D0.BD.D0.BE.D1.81.D1.82.D1.8C.D0.BE.D0.BF.D0.B5.D1.80.D0.B0.D1.86.D0.B8.D0.B9

(43) это замечательно и про это уже было сказано в (4)

(43) зануда

(45) Занудно пытаться потом разбираться в поделиях "не имеющих аналогов".
Бардак в головах.

(46) у тебя что-то распухло после сдачи на спеца и мешает? )
нет бы просто подсказать, а не демонстрировать ЧСВ

(46) ну, ты то пока ничего не предложил. Так что...

Так чем не устраивает решение из (16) ? Маловероятно что даже "тысячи документов в месяц" увеличат время на столько, чтобы вызвать негодование пользователей временем открытия списка подбора документов.

Ответ в (4) и замене неоднозначного НЕ В (Выбрать ...) на
ЛевоеСоединение с условием на is null

(47) У меня распухло еще до спеца. Вот, как увидел код БСП, так пухнет и пухнет.

А я так и не понял, чем РС не подходит. Левое соединение документа с РС будет тормозить или что?

(52) это тоже будет лишняя сущность, остановился на (4)