Добрый день. Подскажите плз наилучший вариант решения. Требуется из одной правленой конфы в другую перенести некий программный механизм, управляющий статусами документов. Там реализовано так: один регистр сведений для хранения самих статусов, а другой для хранения истории изменений. Возникла мысль, раз уж все равно придется этот механизм все равно "допиливать" под новую конфу, почему бы не объединить эти регистры в один, но периодический. А вы как думаете, стоит ли?

Смотря какую смысловую нагрузку несут каждые из регистров. Например первый регистр может хранить дополнительные реквизиты документов (не только этого, который со статусом). Следовательно там история не нужна. Тогда [2]

Если же он хранит только статусы - тогда можно и над [1] подумать.

идеологически - история это периодический. а вот какой смысл вложен в 2 регистра - отсюда не видно

А можно в сам документ как отдельную ТЧ добавить.
Если будут обмены данными, так будет проще контролировать целостность.

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

(2) для быстрого получения текущего статуса. Но в 8.3 такое сама платформа делает

(5) там 8.1 вообще будет (в новой конфе), в той откуда берётся была 8.2

"Тема не раскрыта"(с) :)

Два регистра - может быть для документов  была предусмотрена вероятность не одного, а нескольких статусов одновременно?

(7) Нет, одновременно может быть только один статус.

(3) отличная идея. Это позволит поставить раком всё и всех, если статус надо будет изменить у документа, который закрыт границей запрета. Ну или, если статус документу будут пределывать люди, у которых нет прав на изменение документа (проверяльщики какие-нибудь, которым только чтение нужно и кнопка "Этот документ - зашибись")

(0) Не сделано ли сие творение из соображений быстродействия?

(9) Не говоря уже о записи и проведении больших документов при смене статуса с "зашибись" на "вот теперь совсем зашибись".

(0) думай надо вопросом "зачем", а не "как".
Зачем в источнике отдельный регистр для хранения среза последних? Там кроме состояния еще что-то ил только состояние?
Где и как используется история изменения состояния? Она в приемнике зачем конкретно нужна?
Бывает ли ситуация, когда у документа есть история изменения состояния, но на текущий момент состояния нет ни какого?

(10) нет, просто сначала были сделаны статусы, потом юзерам потребовалось сделать еще и историю. Быстродействие на данном этапе было не критично. Хотя, не факт что оно будет не критично, когда история статусов будет большой...

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

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

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

2 регистра ибо РЛС.

(17) что такое РЛС?

RLS (Record-Level Security)- ограничения на права доступа на уровне записей.

(0) Если подавляющее большинство запросов будут на получение *текущего* статуса, есть смысл в двух регистрах. Иначе нет.

Получение на дату документа, например, не текущее. На рабочую дату - тоже.

(5) Можно подробности?

(0)
Про параллельность слышал ?
Нафига все пихать в один ?

И что это за оптимизация, когда делают не пойми что и непойми зачем и еще и счет за это выставляют ?

Про скорость получения вообще молчу
Регистр сведений - это обычная плоская таблица, что обычный , что периодический

Только в 8.3 кажется реализовали физическое хранение итогов
А у тебя уже есть физическое хранение  де факто