Спасибо за обсуждение. Открыли новое для меня)

Однозначно - первичен контрагент.

pasha_usue
Завтра понадобится в документе указать адрес.

И в чем проблема?
Чем тащить в док гуид элемента справочника адресов по-твоему лучше, например, выборки адреса контрагента из регистра сведений в необходимых случаях? Адрес нужен далеко не всегда, а при чтении объекта документа из бд в твоем случае будет всегда очевидный оверхед - чтение лишнего поля.

А потом удивляемся, почему (типовые) конфы 1С так прожорливы. Мало того, что сама платформа хреновая, так еще и разработчикам прикладных решений насрать на эффективность.

Ты не там ищешь эффективность. Сэкономить n байт из 16 при указании адреса доставки в документе обычно это не экономия. Во сколько ты там решил упаковаться?

Я не очень понимаю предлагаемое тобой решение. Хранить в доке ссылку на адрес, реализованный в справочнике, или сам адрес строкой? Чем оба решения лучше, чем хранить адреса контрагентов/точек доставки в (периодическом) рег-ре сведений и, при необходимости, доставать адреса оттуда для печати какой-нибудь ТТН? При том же групповом проведении многих тысяч доков лишнее поле в доке - это сразу немалый плюс к суммарному времени операции.

Адрес - это характеристика контрагента, а никак не документа отгрузки.

medstrax
Я не очень понимаю предлагаемое тобой решение. Хранить в доке ссылку на адрес, реализованный в справочнике, или сам адрес строкой? Чем оба решения лучше, чем хранить адреса контрагентов/точек доставки в (периодическом) рег-ре сведений и, при необходимости, доставать адреса оттуда для печати какой-нибудь ТТН? При том же групповом проведении многих тысяч доков лишнее поле в доке - это сразу немалый плюс к суммарному времени операции.
Адрес - это характеристика контрагента, а никак не документа отгрузки.

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

Если у контрагента более одного адреса, то это решается через подчиненный справочник точек доставки, которые характеризуются помимо адреса немалым количеством других реквизитов - телефоны, ФИО и пр. Это реальный объект, а не характеристика объекта, как адрес. Идея интерпретировать все как объект неизбежно тащит за собой оверхед.

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

Лишняя косвенность через дополнительные ненужные ссылки, как это модно в типовых решениях, - это всегда доп.тормоза.

Прекрасно. А если у нас распределённая база, и несколько точек создают адреса?

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

Собственно. Я озвучил пул вопросов, которые приводят к текущему решению.
Да. Возможны локальные решения, которые оптимизирует какие-то конкретные ситуации. Но не факт, что ты встретился с данным исключением в текущий момент.

Мне кажется, Паш, что ты мыслишь модными сейчас категориями в духе "пофиг как, но лишь бы разработка шла быстро.
А клиенты затерпят любую какаху, которую мы тут сочиним. Ну памяти/ядер/быстрых СХД добавят, да пофиг. Зато выкатим новую фишечку или сделаем хотелку и получим денег"
Бизнес есть бизнес, тут никуда не денешься, моентизация важней всего, но такой подход мне интуитивно противен, хотя выбора особого нет, надо мириться.