Сегодня случайно обнаружил в одной базе включение регистрации изменений объектов - пользователи включили, чтобы знать, кто и что поменял.
Реализация этого "чуда" была сделана через периодический регистр сведений, где измерения "Пользователь,Компьютер,Объект", а ресурсом была строка неограниченной длины, куда впихнули XML-сериализацию изменяемого объекта.
Наверное, не надо рассказывать, что база пухла прямо-таки на глазах и выгрузка базы перестала загружаться в файловый вариант.
(Почему, думаю, объяснять не надо - попытка проведения документа с контролем остатков приводила к тому, что один документ записывали несколько раз - и на разных компьютерах).

Это история (грустная) - сейчас это "чудо" отключили.

Вопрос, я думаю, известный, но как-то быстро не ищется - как наиболее удачно сделать регистрацию изменений объектов, чтобы не превращала базу в помойку, ну и работала в SQL-варианте, а также позволяла в том же SQL поднять копию базы (и не перепутать изменения).

Заранее благодарен за ссылки.
P.S. чего-то мне уже не нравится эта восьмёрка, которая даже регистр вычистить быстро не может.
Удачи.

(0) это не чудо
это типовое версионирование от УПП/КА

типовое решение, чем не устраивает то?

P.S. восьмерка сырая еще, рано на не переходить

(0) На инфостарте куча вариантов реализации истории, где хранится только изменение реквизитов, а не все объекты. Правда там тоже есть отдельные нюансы.

(1) Почему нужно писать в XML весь документ (со всеми табличными частями), а не только изменяемые реквизиты, а подный объект записывать раз в день или при каком-то определённом накопленном количестве измерений.
И потом - регистр сведений - это вещь индексируемая (там ещё и полнотекстовый поиск включён), а данные изменения маловероятно, что кому-то нужны в таком виде.
Поэтому и возник вопрос - зачем это в базе (500 гигов мусора).

или вот вариант
Книга знаний: История изменений реквизитов документа, реквизитов табличных частей документа

(4) У меня в семёрке всё пишется в обычный журнал регистрации, и только изменения - и получается, что много места, но такого торможения, как в восьмёрке нету.

И З_А_Ч_Е_М писать документ, если в нём вообще ничего, кроме времени записи не поменялось ? Можно же вообще сделать регламентное задание, которое просто будет писать мусор в базу - и то нагрузки на систему будет меньше - регистр-то ещё и на блокировки напарывается.

(7) Я же говорю - есть такие подсистемы на инфостарте. Я видел нетленку с такой подсистемой, там записывается документ только при создании и потом только новые реквизиты. Но есть там минус - сортировку таб.части воспринимает как изменение документа и пишет все строки. А так - чудненькая вещь

(8) Как писать, и что писать, понятно - меня интересует вопрос - куда ?
Регистр сведений, как-то не очень хорошее место для записи того, что нужно достаточно редко.

(9) Почему? По моему самое оно. Хотя если у вас не распределенка, то я за внешнюю базу. Правда это гемморойно

(9) место то самое
то, что перед записью не проверяется модифицированность объекта - фича

Речь таки про регистрацию изменений (фиксацию факта изменения рбъекта) или про версионирование (фиксацию факта того кто, когда и что изменил)?

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

(0)я так делал

http://www.ravepoint.narod.ru/aticles/tricks/methods/keephistory.htm

Судя по описанию в (0) речь таки про версионирование, но какие то ужасы рассказывает ТС 500гигов, действительно много.
Я писал свое версионирование, храню в справочнике(хотя по умному надо в регистре, но мне так удобнее), только измененные значения. В справочнике, потому что специфика требовала, что бы запись каждого объекта была целой(то есть надо видеть что было изменено именно в этот момент, кто сколько чего), вариант в (14) тоже интересный, только абсодютно бесполезен если надо запросом выбрать какие были изменения по пользователю, в каких изменениях мелькала номеннклатура и тд, вообще обработка, почти невозможна или будет слишком сложно (разварачивать каждый объект что бы узнать есть ли там нужные данные, про запросы вообще забыть) .

(15) Там ничего страшного-то не было. Включили версионирование, которое в регистр пишет весь объект.
Потом обменом переносили из одной базы в другую, если что-то шло не так, то удаляли и переносили снова.
А потом - база стала очень большой и неповоротливой.
Если в регистре хранить сам факт изменения, то это так много места не займёт.
Если хранить строку переменной длины, то для SQL это поле BLOB, которое, насколько я помню, с 2048 байт начинается (или какой там размер сегмента поставили).
Вопрос первый - зачем все версии всех объектов в одном регистре сведений - про сбор всех фактов изменения в одном регистре я ничего плохого не говорю, но сами изменения нужно хранить отдельно.

(15) Что касается хранения данных внутри самого объекта - это смертельный случай, так как при любом получении объекта из базы мы загрузим в память всю эту кучу - вопрос - а оно нам надо.

P.S. продолжаем обсуждение - решений много.
Но у меня ещё один вопрос - насколько часто бывает нужна это "чудесная" запись изменений, и насколько в ней востребована возможность быстрого поиска по объектам и реквизитам.
Например, если мы пишем все изменения в текстовый файл, то поиск строки GUID в этом файле через RegExpt будет не такой уж затратный, а запись - плюнул и забыл.
Удачи.

(0) надо нормально спроектировать профили пользователей и не давать лишних прав, тогда и необходимости такой не будет.
В теории.

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

>>Например, если мы пишем все изменения в текстовый файл, то поиск строки GUID в этом файле через RegExpt будет не такой уж затратный, а запись - плюнул и забыл.
Надо выбрать все изменения по объекту? Считай ВЕСЬ файлик  метров на 200-300(вариант хранить для каждого объекта метаданных свой файлик). Как определить какая именно номенклатура была в табличной части? Та которая сейчас с таким названием или та которую потом переименовали?

(18) Обмен регистрирует факт изменения объекта в определённый момент времени (в промежутке между обменами), но не фиксирует сделанных изменений.
(17) Вопрос в том, что пользователь должен иметь возможность править документы и вводить их (а иначе вообще зачем нужны пользователи) просто иногда пользователь может сделать что-то не так, тогда нужно ему объяснить, что он был не прав.
(19) Вопрос в том, что если это нужно один раз в неделю, то пофиг, сколько будет жеваться файл - мы получим ответ, а вот писаться файл будет гораздо быстрее, чем регистр.
И, если кто-то переименовал номенклатуру, то для системы документ не поменялся - поменялась номенклатура, и то, что на печати было одно, а будет другое - это вопрос проектирования системы, где допускается переименование товаров.

(24)Хотя да если хранить гуид вместо наименования, вопрос решится.

в БСП версионированию 100 лет в обед уже;
принцип примерно тот же: в ресурсе РС хранилище значения с пожатым бинарным xml (fastinfoset).

(20) " мы получим ответ, а вот писаться файл будет гораздо быстрее, чем регистр.  " разница если и есть то очень незаметная

(20) тем более чем больше файл тем дольше будет пистаься. чего не скажешь о регистре.

(24) В регистр пишется очень быстро, а вот строки неограниченной длины или двоичные данные - они пишутся одинаково медленно.
Если файл писать последовательно (командной дозаписи), то от размера файла вообще ничего не зависит - от размера зависит только поиск. Только вот 1С не умеет писать в режиме дозаписи.
С хранилищем должно быть проще, но придётся хранить все изменения одного объекта в одном хранилище, а в регистре писать только факт изменения, ну и какие реквизиты менялись.
P.S. просто, данные об изменениях нужны в течении какого-то периода - потом их можно удалять - регистр придётся чистить, а если у нас файл, то их должно быть несколько - и менять каждый день, чтобы не вырезать кусок.

...

(23) В общем, подумали и решили, что писаться в базе будет в регистр, но не всё, а только изменения.
И будет процесс (фоновый и ночью), который этот регистр будет "укладывать" в другую базу, где будет жить история изменений.
При создании рабочей копии базы мы максимум запишем в регистр только один день, а если кому-то нужно будет выявить историю, то будет подключаться к другой базе, в режиме только чтения и смотреть, что и кто делал.
Потом базу истории можно рассматривать как BackUp.
Идея файла, отдельной sql-базы или хранения в текущей базе отпадает, так как у нас несколько пользователей, и не хочется делать несколько файлов или несколько соединений к базе истории.
Что вы думаете по этому поводу ?

>>или хранения в текущей базе отпадает
эта идея почему отпадает?
(27)>>Что вы думаете по этому поводу ?
Очень много написать придется, особенно что бы реализовать:
>>Потом базу истории можно рассматривать как BackUp.
При таких объемах я бы заморочился созданием правил и выгрузкой изменений через РИБ(именно изменений). И не хранил бы историю в базе вообще.

(27)[Что вы думаете по этому поводу]
не удачный вариант
любое хранение версий вне базы порочно и бессмысленно

(28) Пока делается ежедневный BackUp sql, который прекрасно разворачивается обратно (когда нужна тестовая база - быстрее его развернуть).
Потом, основная задача - видеть кто и что поменял, в случае обмена данными мы видим только общие изменения за какой-то период или придётся очень часто вызывать обмен.

(29) Хранение изменений в самой базе очень сильно увеличивает размер базы, что сказывается на времени резервного копирования. Основная цель вынесения регистрации изменений в отдельное место - это снижение нагрузки на основную базу и уменьшение её объёма.

Кроме того, регистрация изменений - это классический пример очереди, когда запись идёт в конец, а стирание должно идти сначала.

Отдельно обсуждается вопрос регистрации изменений документов только после первого проведения - пока документ не проведён, это заготовка, в которую вводят данные и никакого смысла в регистрации изменений в нём нет.

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

P.S. стереть регистр в лоб не получилось - памяти не хватило, зато работа с регистром на уровне выбора записи и анализ затрат процессорного времени показал, что на самом деле никаких проблем в поиске нет - тупит система только в случае выборки всего набора записей (их просто очень много), а отборы по объекту работают достаточно сносно.
Индексы делают своё дело.
Но, оказалось, что никто и не разу в этот регистр не заглядывал - посему он не очень-то и нужен.

У меня логирование законодательно обязательно. Рассматривали варианты, остановились на какой-то разработке (наверное с инфостарта) на справочниках. Удобный поиск, удобно организовывать защиту. Хранит только измененные реквизиты. Допилила логирование только изменений и логирование независимых регистров. С 4 марта запустили, в начале апреля буду замерять, на сколько пухнет база.

(31) Так в ЗУП-е оно должно быть, так как есть закон о персональных данных (а там данные работников).
Что касается управленческих баз, то там персональных данных нет, так как ФИО работника и его рабочий телефон не являются персональными данными.
Другое дело, что у нас была обработка, которая чистит ПрайсЛист и создаёт новый, а "умная" система логирования это всё записывает (вполне понятно, что достаточно было бы зафиксировать только факт очистки Прайс-Листа).