Версионирование регистров сведений (необъектных данных) - история изменений по версиям записей регистров сведений - ВНОД
ВНОД – отдельная (дополнительная) подсистема, которая построена на основе типовой подсистемы «Версионирование объектов».
Предназначена для сохранения и анализа изменений независимых (периодических и непериодических) регистров сведений, с точностью до состава измерений, ресурсов и реквизитов записей.
Предназначена для сохранения и анализа изменений независимых (периодических и непериодических) регистров сведений, с точностью до состава измерений, ресурсов и реквизитов записей.
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
А если нужно по простому - один-два регистра сведений в журнал регистрации - гуглите на мисте "логирование изменений записей регистров сведений" (ссылку на стороний ресурс данный портал запрещает). А в целом в платформе 8.3.11 добавили функциональность История данных которая работает и с регистрами сведений.
(1) Да, пожалуйста, пользуйтесь любым решением, которое подходит именно Вам:
- любое решение, которое логирует (архивирует) журнал регистрации по регистрам сведений, с точностью до состава измерений, ресурсов и реквизитов.
- если у Вас платформа 8.3.11 и подходит механизм "История (изменений) данных" и есть возможность включить механизм (указать требуемый режим совместимости, создать и включить регл. задание для обновления истории, указать для каких именно объектов конфигурации будет вестись история изменений)
- в том числе и по производительности
НО повторюсь, преимущества данного решения:
- Легко интегрируется в любую конфигурацию на базе платформы "1С:Предприятие 8.2/8.3" (в т.ч. и на управляемых формах).
- При объединении не требуется вносить изменения в объекты исходной конфигурации.
- Для работы механизма не требуется настраивать права доступа (административные права потребуются - только для настройки версионирования).
- Не требует наличие типовых справочников, типа «Пользователи» и т.д.
- Сохраняет только изменения - версию записей регистра, если между версиями были изменения.
- Работает, если были изменения по метаданным, например: добавлен или удален ресурс регистра.
- Минимальное влияние на производительность.
- Знакомый интерфейс типовой подсистемы «Версионирование объектов».
- Для хеширования данных использованы возможности платформы «8.3», для 8.2 - в «Windows 7» и последующих версиях - платформы «.NET», если нет платформы «.NET», то функции «Библиотеки стандартных подсистем».
- Открытость кода.
p.s. если "того "позволит платформа - подсистема будет реализована - как расширение.
- любое решение, которое логирует (архивирует) журнал регистрации по регистрам сведений, с точностью до состава измерений, ресурсов и реквизитов.
- если у Вас платформа 8.3.11 и подходит механизм "История (изменений) данных" и есть возможность включить механизм (указать требуемый режим совместимости, создать и включить регл. задание для обновления истории, указать для каких именно объектов конфигурации будет вестись история изменений)
- в том числе и по производительности
НО повторюсь, преимущества данного решения:
- Легко интегрируется в любую конфигурацию на базе платформы "1С:Предприятие 8.2/8.3" (в т.ч. и на управляемых формах).
- При объединении не требуется вносить изменения в объекты исходной конфигурации.
- Для работы механизма не требуется настраивать права доступа (административные права потребуются - только для настройки версионирования).
- Не требует наличие типовых справочников, типа «Пользователи» и т.д.
- Сохраняет только изменения - версию записей регистра, если между версиями были изменения.
- Работает, если были изменения по метаданным, например: добавлен или удален ресурс регистра.
- Минимальное влияние на производительность.
- Знакомый интерфейс типовой подсистемы «Версионирование объектов».
- Для хеширования данных использованы возможности платформы «8.3», для 8.2 - в «Windows 7» и последующих версиях - платформы «.NET», если нет платформы «.NET», то функции «Библиотеки стандартных подсистем».
- Открытость кода.
p.s. если "того "позволит платформа - подсистема будет реализована - как расширение.
Толковая разработка - удобно что поставил подсистему, настроил и все работает
Настройки, опять же, гибкие, регламентное задание очистки версий позволяет контролировать занимаемое место
Открытый исходный код тоже большой плюс - формат наименования ключа записи, например, под себя переделал
Отчет о сравнении похож на типовой БСПшный - раскраска, легенда, все как привык пользователь
Хотелось бы чтобы ещё позволял больше двух версий сравнивать)
Ну и наконец система развивается, так что ждем дальнейших улучшений
В общем автору большой респект и плюс в карму!
Настройки, опять же, гибкие, регламентное задание очистки версий позволяет контролировать занимаемое место
Открытый исходный код тоже большой плюс - формат наименования ключа записи, например, под себя переделал
Отчет о сравнении похож на типовой БСПшный - раскраска, легенда, все как привык пользователь
Хотелось бы чтобы ещё позволял больше двух версий сравнивать)
Ну и наконец система развивается, так что ждем дальнейших улучшений
В общем автору большой респект и плюс в карму!
(3) Хотелось бы чтобы ещё позволял больше двух версий сравнивать)
- Разрешено сравнение любого количества версий, как это сделано в подсистеме версионирования БСП (важно - надо понимать, что при сравнении большого количества версий происходит потребление памяти).
- При сравнении измененных (раскрашенных синим цветом) версий показываются изменения не по всей строке записи в целом, а по каждому значению (также изменением считается, если между версиями было изменение метаданных).
- см. сравнение версий в публикации.
- Разрешено сравнение любого количества версий, как это сделано в подсистеме версионирования БСП (важно - надо понимать, что при сравнении большого количества версий происходит потребление памяти).
- При сравнении измененных (раскрашенных синим цветом) версий показываются изменения не по всей строке записи в целом, а по каждому значению (также изменением считается, если между версиями было изменение метаданных).
- см. сравнение версий в публикации.
(6) Пожайлуста, положительные отзывы, это приятно.
По вопросу -
при сравнении и объединении с основной конфигурацией, как показано на 1-м скриншоте (делался в обычном режиме, но для управляемого также работает, чуть другой интерфейс), нужно указать все объекты, которые относятся к данной подсистеме (не затрагивая свойства и объекты основной конфигурации), как и было описано в публикации
- при объединении не требуется вносить изменения в объекты исходной конфигурации
По вопросу -
при сравнении и объединении с основной конфигурацией, как показано на 1-м скриншоте (делался в обычном режиме, но для управляемого также работает, чуть другой интерфейс), нужно указать все объекты, которые относятся к данной подсистеме (не затрагивая свойства и объекты основной конфигурации), как и было описано в публикации
- при объединении не требуется вносить изменения в объекты исходной конфигурации
(15) Добрый!
Влияние на производительность - минимальное:
- количество записей регистра - не влияет на производительность, т.к. последний номер версии записи регистра выполняется оптимальным запросом - получается максимальный номер версии.
- для формирования ключа записи берутся все измерения регистра (которые участвуют, при записи набора записи) и период (если регистр периодический), иначе НЕ будет соблюдаться уникальность ключа записи регистра,
НО есть возможность отключить (не учитывать) период (при версионировании) - требуется настройка - см. описание к публикации,
также есть возможность формировать ключ записи регистра в одном месте - по имени регистра - не требуется формировать имя ключа записи регистра по измерениям - все изменения сохраняются на имя регистра - см. описание к публикации.
- сохраняет только изменения - версию записей регистра, если между версиями были изменения,
т.е. в данном случае - не затрачивается время на сохранение версии записи регистра.
по замерам - точно не могу сказать - все зависит от характеристик компьютера - сервера.
у меня - получение ключа записи регистра, формирование имени ключа записи регистра, получение изменений между версиями, сохранение версии, если были изменения - составляется приблизительно 0,5 сек. - в НЕ кешированном (код выполняется - первый раз), 0,01 сек. - в кеше.
Влияние на производительность - минимальное:
- количество записей регистра - не влияет на производительность, т.к. последний номер версии записи регистра выполняется оптимальным запросом - получается максимальный номер версии.
- для формирования ключа записи берутся все измерения регистра (которые участвуют, при записи набора записи) и период (если регистр периодический), иначе НЕ будет соблюдаться уникальность ключа записи регистра,
НО есть возможность отключить (не учитывать) период (при версионировании) - требуется настройка - см. описание к публикации,
также есть возможность формировать ключ записи регистра в одном месте - по имени регистра - не требуется формировать имя ключа записи регистра по измерениям - все изменения сохраняются на имя регистра - см. описание к публикации.
- сохраняет только изменения - версию записей регистра, если между версиями были изменения,
т.е. в данном случае - не затрачивается время на сохранение версии записи регистра.
по замерам - точно не могу сказать - все зависит от характеристик компьютера - сервера.
у меня - получение ключа записи регистра, формирование имени ключа записи регистра, получение изменений между версиями, сохранение версии, если были изменения - составляется приблизительно 0,5 сек. - в НЕ кешированном (код выполняется - первый раз), 0,01 сек. - в кеше.
Вопросы с вознаграждением
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|