Народ!

Для реализации одного механизма требуется сопоставление склада и склада резерва.
Одному складу ВСЕГДА будет соответствовать ОДИН склад резера.
Как лучше реализовать сопоставление?
Через реквизит "СкладРезерва" или через регистр сведений "Склад - Склад Резерва"

Спасибо!

и на зачем тут регистр заводить? голосовалку? ;)

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

(0)РС только если нужно хранить историю..а так - реквизита вполне хватит

(2) может, у него зарплата от количества таблиц зависит

каждый вздох - таблица

все что не относится к  сущности (модели объекта) -

в другие сущности.

тем более сопоставления.

В регистр. Дабы не утежелять чтение объекта везде и всегда, только для "одного механизма".

(6)Не утяжеляя чтение объекта, ты утяжеляешь базу лишней сущностью.

(7) а тут уже надо смотреть в корень - хз что там за механизм будет...

регистр сведений делается в двух случаях

1. разделение прав на записть справочника и свойств
2. требуется переодичность

все остальное - от лукавого

(9) у меня доп признаки для документа вынесены в РС

(10) согласен, зачем при чтении лишнее читать в (9) этого нет

(7) Я сказал только свое мнение. Конкретное решение на самом деле может зависить от многих факторов. Но если упростить до "реквизит vs регистр" - то мое мнение таково. Все лишешнее - из объекта убрать. Не навязываю.

(12) Если убрать все лишнее отстанутся только код и наименование.

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

(9) 3. Для совместимости с будущим обновлением
Т.е. завел РС и голова не болит, что новое обновления затрет твой реквизит

Решение через реквизит:

Минусы:
- В таблицу справочника добавляется колонка и для всех складов будет хранится значение Склада резерва.

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

- Чтение и запись эл. спр. Склады будет выполняться дольше.

Плюсы:
- Простота реализации.
- Легко получать значение склада резерва.
- Во всех отчетах можно будет группировать, отбирать по складу резерва.

Решение через рс:
Минусы:
- Для получения склада резерва лишнее соединение с таблицей рс.
- Пользователь наверняка захочет в форме элемента спр. Склад видеть склад резерва - придется код писать.

Плюсы:

- хранится столько записей соответствий Склад - Склад резерва сколько действительно необходимо. Т.е. никакой избыточной информации.

- складов резерва для одного склада можно сделать много. и вообще возможности модификации такого механизма намного шире.

- не тягаем за складом - склад резерва при любом чтении и записи эл. спр. склад.

Выбор метода реализации зависит от задачи. Мне больше нравится через рс. Уверен что пользователи что-то забыли и только реквизитом будет не обойтись.

(15) это вам не семерка, "затирание" реквизиту мало грозит

А насчет "излишеств" - сколько планируется записей в справочнике "Склады"? Десятки тысяч?
Более жизненно ИМХО просто десятки максимум.
Так что реквизит вряд ли что-то заметно "утяжелит"

(17) Угу и на форму он автоматом добавиться? Или каждый раз будешь глазками сравнивать, так ничего нового в этом справочнике на форме не появилось

(16) Так вроде бы в 8.2 в конфигураторе можно пошаманить и запись в РС  будет как реквизит видеться

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

(21) Сас себе противоречишь

если конфа на поддержке - то я за РС.
ну и никогда не говори "всегда" ;)

(20) Т.е. можно отображение на форме элемента справочника связанного с этим справочником значения из какого-то рс решить только настройками свойств объектов конфигурации?

(22) в чем же?

(24) Да. И даже  интеракитвный ввод и прочую хню, по крайней мере в 8.1

для регистра есть например такие подводные камни как подписка на событие, RLS и тд

например совсем не просто сделать подписку на изменение значения элемента справочника и т.д.

(25) см (21)
"справочник нужно добавлять  реквизит, если он будет заполнен у большинства элементов..., если нет - то регистр сведений. В данном случае, справочник склады обычно маленький, поэтому проще реквизит"

Вывод неправильный .
Твое правило: если х = 1 то А, иначе Б
Состояние х = 1
Вывод: Б

(27) или например контроль уникальности чего-то

кроме того такое поле не выведешь в динамический список, проблеммы с сортировкой по нему....

(9) Еще в случае, когда на миллион записей данное значение будет заполнено у нескольких сотен...

(26) С использованием эл. формы поле ввода?

Зачем? Табличное поле или используй перейти

(32) Через таб. поле понятно как. Я уж было подумал что можно связать с полем ввода.

(28) Ну собственно тут не совсем противоречие. Если в справочнике склады будет большинство реквизитов заполнено (а в маленьком справочнике оно так и будет) то нужно реквизит.

А не лучше ли прямо в доке определять склад резерва и не засорять справочник?

(35) на основании чего? Причем это нужно сделать прозрачным для пользователя

(35) На основании решения пользователя.

(37) Пользователь выбрал склад А, автоматом должен выбраться резерв со склада Б
Если он выбрал склад АБВГД, то соответсвенно резерв со склада XYZ

А если он будет выбирать кучу реквизитов ... так может и сумму не рассчитывать на основании цены и количество, а пусть сам менеджер ручками считает, "На основании решения пользователя."

(38) А как арифметика от воли пользователя меняется. А вот склад резерва вполне может. Потому что если связь "жесткая" один в один, реквизит вообще не нужен ни в справочнике, ни в документе.