8.2 КА.

Связь: Договор, ВидНоменклатуры, ТорговаяТочка, Маршрут Доставки, Маршрут Заявки.

Информация непериодическая.

Необходимо знать кто, когда, что изменил(старое новое значения)

Торговых точек 2300 * разные виды продукции = 10000 с перспективой до 20000. То есть в пике будет 20000.

Связь используется при заполнении путевого листа, т.е. скорость учитывается, но на 20 тысячах будет незаметно. Также при формировании различных отчетов.

Варианты:

1. Вариант непериодический неподчиненный РС(сразу плюс контроль уникальности измерений) + индексировать все поля + [самая большая проблема] хранение истории изменений [код + доп. РС + через ЖПО определять события - изменение,удаление,добавление].
2. Справочник без иерархии + реализовать контроль уникальности реквизитов + индексировать все поля + включенное версифицированние справочника.

Вопрос: кто сталкивался с подобной задачей - что посоветуете ?

"Необходимо знать кто, когда, что изменил(старое новое значения)".
Расшифруй с примерчиком.

(1)

Договор1-Вид1-Магазин1-Маршрут11-Маршрут22
Далее пользователь меняет
Договор1-Вид1-Магазин1-Маршрут12-Маршрут22

Нужно получить информацию кто, когда поменял Маршрут11 на Маршрут12.
То есть задаем отбор по полям Договор1-Вид1-Магазин1-Маршрут12-Маршрут22 = получаем = Договор1-Вид1-Магазин1-Маршрут11-Маршрут22 + ДатаИзменения + Ответственный

Для этого как раз подходит версифицированние в КА.

выдиться РС, т.к. много понятного функуионала, а справочник станет массивный и практически неуправляемый, хотя на правах ноу-хау мож БП заюзать "ДоставкаТовара"
Старт - выезд с базы
Финиш - заезд на базу

ну и итерационная ветка БП "Маршрут из Точки А в точку В"

ИМХО, это периодический регистр с ресурсом Ответственный. Тогда не надо заводить реквизит ДатаИзменения.
А для чего надо знать, кто изменил маршрут? Будете его бить? )))
Все встанет на свои места, если будешь плясать не от придуманной структуры, а от реального отчета. У отчета есть форма, цель...

регистр сведений, в нем уже реализован контроль уникальности.

(4) Отчетов много. Приоритетная цель связи - заполнение путевого листа.
Цель контроля - уменьшить количество ошибок. Сразу указать конкретному работнику - на конкретную ошибку.
Продумывал вариант периодического РС - но он не решает главную проблему - какие именно данные изменили.

(5) Да, в (0) в плюсах РС я это отметил. РС все красиво, но что делать с историей изменений ?

(3) 20 000 элементов. Что значит неуправляемый ? Если у меня будет РС без периода - то условия будут задаваться в ГДЕ, что сравнимо по быстродействию с запросом по справочнику.

БП в виде объекта бизнес-процесс тут не нужен.

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

Если приоритет Путевой лист, то привяжи РС к нему.

(7) Можно сделать, но остается нерешенная проблема - какие данные были изменены.

(8) Т.к. приоритет путевой лист - необходим контроль за людьми которые заполняют связь из (0).

В путевом листе добавь реквизит Ответственный. Не авторам запрети менять проведенный документ.

(10) Это уже другой этап.

С такой логикой - и журнал регистрации не нужен ... у пользователей же есть голова на плечах, они ведь отдают отчет в своих действиях. Да ?

(12)Да. Иногда лучше изменить логику работы, чем подтирать за каждой ошибкой. Заполненный документ несет в себе регистрацию по времени (то бишь историю), ответственного (чтобы другие не лезли), проведение по регистрам (чтобы отчеты слепить).

(13) Нет.
Заполнение регистра - первый шаг делают работники с должностью ХХХХ.
Заполнение документа - второй щаг делают работники с должностью YYYY.

Слишком уж замгруженная аналитика и при этом кажется что можно учет сделать гораздо проще. Как говорят -"Гениальное просто". Попробуй тщательно пранализировать саму задачу и уверен вы придете к очень простой схеме учета.

(15) Схема сложная. Связь описанная в (0) только 1 из 4-х. Усложнять просто, упрощать сложно ... можно будет попытаться еще раз все пересмотреть. Но сейчас я вижу - что эта одна единственная возможная схема.

Хозяин - барин.Твоя база - твои руки.
(14)Однако подход "Заполнение регистра - первый шаг делают работники с должностью ХХХХ" мешает тебе отрешиться от отдельных шагов к общему осмыслению. Мне пункт 1 не так очевиден например.

(17) Осмысление простое. Путевой заполняется просто - выбрал маршрут - нажал кнопку заполнить - к задаче описанной в (0) не имеет отношения. Все уже сто раз написано здесь выше. Ваш пост ни о чем.

(18)Для формирования маршрутов ввести документ "Формированием маршрутов" с ответственным лицом плюс Регистр сведений "Утвержденные маршруты".
..."Ваш пост ни о чем". Тебе виднее )))

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

Вообще-то не документ привязывается к регистру сведений, а наоборот документ является регистратором. Ты почему-то совсем не хочешь добавить документ. Тебе либо справочник, либо РС без регистратора.

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

Да ладно, не обижайся. Мне показалось,что ты занервничал, когда тебе предложили другие варианты.

И у тех и у других вариантов есть преимущества и недостатки , вот здесь обсуждалось
v8: Производительность объектов на платформе 8.2

Я выбрал справочник по причине
Нет проблем с уникальностью
Периодика не нужна
Меньше проблем с транзакциями
На записи быстрее регистра (на чтении правда чуть медленнее , но запись выполняется на порядки чаще)
У меня 14 полей , регистр очень громоздючий получется
Храню не ссылки на объекты а строковые представления (переносимость и возможность удаления объектов с сохранениями записей о них в логе)

патамушта гладиолус...

Одннозначно РС, Периодический, в реквизиты ставишь пользователя и видишь всю историю изменений. Срезом последних будешь снимать актуальное состояние.

(0) Документ с зависимым периодическим регистром сведений

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

какого лешего эта информация изначально не в периодическом РС лежит?

(30) Пока нигде не лежит.
(27) Ты вообще читал тему ?

(24) хорошая тема.

(32) А изменения насколько часто будут вноситься?

(33) Условно редко. По мере того как будут появляться новые клиенты - торговые точки + иногда будут изменяться данные по старым точкам + перегруппировка маршрутов.

+(34) Статистики такой у меня нет. Навскидку 0-20 изменений в день.

(35) Тогда надо не на производительность смотреть, а на удобство и надежность.