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

Если условия недостаточно ужасны, я еще добавлю деталей.

В типовых уже есть этот механизм
Используется РС а не справочник

(1) Ну да и я об чем. А работадатель хочет справочник и не какой то а справочник пользователей.

Т.е. не нужен никакой справочник
РС + параметры сеанса
Для удобства просмотра/удаления/правки настроек предусмотреть кнопочку/ссылочку в справочнике Пользователи

(3) Я понимаю... Вопрос в том, как объяснить это работадателю...

(0) А почему нельзя так писать? Кто сказал? А может и можно.
Чем РС принципиально отличается от справочника?

(5) наличием ссылки

(0) создай форму списка где мастер-таблицей будет справочник "пользователи", а деталь-таблицей данные из РС.
В форме элемента "пользователи" сделай закладку с данными из РС.

Думаю, именно это и хочет заказчик и в его картине мира - это "справочник".

(5) Ну как минимум тем что в справочнике >пользователей< хранятся важные и нужные данные напостоянку. А если мы будем шуровать там в куче таблицах и реквизитах (а их правда куча), то важные и нужные данные в важном и нужном справочнике как-то не защищены что ли получается... Слабовато у меня звучит, поэтому я и обращаюсь

(7) Да нет, там без вариантов... Заказчик хочет чтобы весь старый код обращения к >реквизитам< пользователя остался прежним, а значит для этого надо перезаписывать именно реквизиты.
И ТЧ.

(0) Кстати, слова "кошмар", "ужас", "катастрофа"... следует выбрасывать из бытового и делового обращения - никакой пользы для жизни и дела они не несут.

Оставим эти термины полит-ток-шоу.

(9) Напиши функции/процедуры в модуле менеджера справочника Пользователи
А что там внутри уже пофиг

Короче исходя из всеобщего затруднения выходит что никто не видит проблемы в хранении временных данных сеанса в самом важном справочнике базы?

(12) Уважайте любой каприз работодателя за его деньги.

(11) Да нет, там не пофиг. Вот я ответила в сообщении 9. Реквизиты обязаны быть перезаписаны по идее заказчика, чтобы код обращения к ним остался тем же.

(9) я описал решение в (7). Заказчик может не понимать БД и говорить парой понятных ему слов. Бывает некоторые думают, что в 1С есть только справочники и документы. Просто нарисуйте формы.

(10) Ага и заменим термины говнокод на темная архитектура
Костыль на workaround

Прикольно будет когда оно начнет на блокировки попадать и грязное чтение

(15) По-моему сообщенное в (9) сводит на нет ваше решение. Заказчик требует не трогать код в некоем документе. Допустим код "Пользователь.Склад" должен остаться тем же. При этом склада у пользователя должно быть два и меняться они будут в зависимости от параметров входа

(18) в (9) нет четкого понимания кто чего хочет.

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

(19) Вам задачу полностью расписать? Выложить ТЗ?
На самом деле не очень понимаю зачем, вопрос заключался в том, какие аргументы есть для объяснения почему нельзя сделать описанное в (0)

(17) А это возможно в данном случае разве?

(18) Слишком много гипотез в одном предложении.
Разбейте задачу на составляющие и решайте последовательно.

(18) Это изврат
1. Почему Пользователь.Склад вместо ПараметрыСеанса.Склад?

И вот параметры сеанса можно было бы заполнять как надо при входе

(24) Потому что "Пользователь.Склад" уже написано в документе, а документ трогать нельзя. Ну то есть можно, но заказчик запрещает. Я должна его уговорить. Для этого мне нужны аргументы почему ИМЕННО это изврат

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

Уговорила! Ура!
Но вообще то все равно было бы интересно понять какая реальная аргументация есть. Я удивилась, что по сути все более или менее согласны, что так нельзя, но никто не может привести железных аргументов.

(26) Дада, это именно наш случай

(25) Создай общий модуль клиентский "Пользователь"
И там
ПЕРЕМ Склад Экспорт

:)

(29) Хаха, а табличную часть в модуле получится создать?)))

v8: Справочник vs Регистр сведений

(30) ТЗ почему нет?

(32) Кстати действительно... Спасибо за вариант!

Самый самый костыль было бы ничего не трогать
А перед обращением менять (перезаписью) реквизит Склад у справочника Пользователи программно

(34) Ну да, именно это и требуется. Только не перед обращением, а в момент входа

(34) Просто в момент постановки задачи, я была уверена, что это неприемлемая постановка. Но после обсуждения поняла, что реальных аргументов против не существует. Присутствует просто нарушение логики порядка хранения данных, но реальных проблем нет.

(36) дада
а потом второй сеанс с тем же пользователем запустят и привет

(27) Да можно...

(36) ну храняьт же остатки и цены в српавочнике номенклатуры, почему нельзя склад хранить я так и не понял

(39) Про остатки и цены в справочнике - что-то вряд ли. Ну то есть понятно что кто-то хранит, но что это считается нормально - все же вряд ли.