В новой БП 3.0 заявлено

"Для отдельных документов и справочников включен механизм версионирования;"

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

имеет смысл только когда права нормально нарезаны, и бухи лишний раз не перезаписывают обьекты, а пока есть привычка (в том числе и у преподов самой 1с) закрывать через кнопку "ПровестиИЗакрыть" - версионирование зло...

то есть сначало запретить неоперативное проведение...

(0) плюсы - получаем версионирование
минусы - пухнет база

(2) Классный ник. В смысле - соответствует контексту т.с. )

для трехзвенки на серверах от 100К зелени с мегабыстрыми винтами и кораваном озу - добро, для остальных случаев фантик из коробки для наивных бабищ

(0) если версионировать объекты без графических реквизитов, то нормуль, но стандартный механизм надо допиливать, чтобы исключить поля типа хранилище

(2) Коэффициент распухания какой?

А есть какие нибудь картинке как это выглядит?

(5) "графических реквизитов"? это реквизиты где картинки хранятся? Вроде бы в БП таких нет

(7) сканы счетов (накладных поставщика), не?

(8) Нету такого

классный механизм, мечтал о таком в 7.7, если не нравиться отключается

(10) НУ такой у меня в 7-ке есть, правда инфу храню во внешних файлах (sqlite)

2(6) Версии это отдельный РС. При каждой записи объекта, для вида которого назначено версионирование - туда добавляется э... запись.
коэфициент распухания? ну не знаю - ну посмотри в конфигуратор. сделай запись одного объекта, посмотри сколько она весит..
И индексы... :)

Если база SQL, то таблицу регистра можно вынести в отдельную файловую группу и пусть себе там пухнет. Ее даже можно не бекапить ИМХА.

2(13) о, у меня вопрос - как реструктуризация данных влияет на базу с несколькими файловыми группами?

(0) использую в УПП, кроме раста размера базы минусов нет, зато плюс ограменный - поиск автора кривой даты в договоре или счета  в банке происходит мгновенно

(15) Почти на всех своих проектах используем версионироние почти с того момента как оно появилось.

При запуске вообще помогает избежать конфликтов, в среднем за квартал база вырастает на 100 гигов, на 200 пользователей при условии постоянных пеерпроведений и арсчетов себестоимости

(16) тотальное версионирование - а на куя,
зачем мне 100 релизов РТиУ ?

а кстати, почему оно туда пишется? потому что версия объекта изменилась?

70Гб база, версионирование работает чуть больше года, версионируются НЕ все документы/справочники, Версии занимают 3Гб

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

(20) типовая пишет неизмененные реквизиты ?

(21) Типовая тупо сериализует объект в XML

Голосовалку бы прикрутили

(0)В типовой утп для Украины пишется весь объект. База не сильно пухнет - 10 гигов за год при общем размере 40. Но есть проблема - если использовать урбд то оно гоняет версии тудам сюдам и обмены получаются огромные. Потому и отключили

(14) Я не проверял. Скорее всего таблица переместится в основную группу. Ведь она заново создается. Только зачем ее реструктуризовать? В крайнем случае можно опять переместить.

+(24)Если бы они писали только изменения было бы круто. А так лучше ну его нафиг

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

При перепроведении тоже пишется?

Пишется, даже если реквизиты не изменились.

(29)  чего ж так дерьмово-то

Думаю обойтись без УРИБ. Сейчас 40 гигов на скуле. И раз негативных отзывов не много, то попробуем этого зверя

(31) в каком релизе ?

(32) Сейчас на 2.0. (и русть там годик еще живут) Просто новые фирмы уже на 3.0 разворачиваю, вот и думал включать или нет

(33)  выключит всегда можно ж

(34) А зачем наступать на грабли, если о них можно заранее спросить ? :)

(35)  да все равно пока сам не пощупаешь, фиг чего поймешь

(20) пишется весь объект, сериализованный в бинарную форму быстрого хмл-преобразования, при каждой записи, не глядя на измененные реквизиты. Дата, номер версии, владелец и сам бинарник хранится в РС

(37)  а ссылки там в каком виде?

(37)
В пень такое.
Написать версионирование одного/двух документов с регистрацией только измененных реквизитов - за один день спокойно управиться можно. Если с перекурами и т.п

(39) А смысл курочить типовые?

(17) При запуске как раз критично, после квартала оставляем версионирование там где критично, но все пользователи уже знают что их действия проследим, а потом уже пофигу

файловая быстро помрет, однако

(39) зачем писать? все настраивается, отмечаешь какие доки или справочники версиоировать и все.

(38) ссылка одна, версия объекта другая

Хреново если адрес контрагента меняют, ибо РС не версионируется )

(40)Зачем курочить? подписки на событие и усе

(43)
Да, но при любой перезаписи идет новая версия объекта. Я мало видел, что б документы всегда только оперативно проводились.А часто бывает, что они сначала записываются, а потом проводятся - это две версии одного объекта. Плюс та, что непосредственно в базе

Интересно. Я тут задался вопросом а нет ли сжатия в MSSQL для определённых таблиц

И о чудо... есть !

(43)  я имею ввиду, например, документ ссылается на элемент справочника контрагенты. Как эта ссылка хранится в истории? В виде обычной ссылки? А при необходимости посмотреть вид старой версии документа вытягивается и старая версия контрагента?

2(48) нет

(49)  вытягивается просто текущий элемент? Не из истории? Хреново

(50) читай (37)

(50)
Фигассе хреново. Этож полный слепок базы при каждом изменении одного элементы делать надо. Ну можно конечно извратиться с фиксацией времени версий. И аналог среза последних по версиям. Но это капец :)

по-моему решение с записью хмл-сериализованного объекта на столько красивее чем запись изменившихся реквизитов, что стоит пожертвовать местом

а кому место критично - разрулить организационно. Вытащить таблицы на другой диск или сливать старые записи в архив в другую базу

короче другие решения право на жизнь не имеют ибо не красивы

(53)
Та ну ладно. А при изменении структуры элемента как сериализация отработает? Или все версии пересеарилизируются?

(52)  ну, наверно, это действительно нафиг не нужно

(50) возможность сравнения любой версии с любой версией того стоит

в противном случае придётся вычислять инкременты

2(50)Серьезно? А на какой глубине следовало бы остановится? Документ ссылается на контрагента, у контрагента есть подчиненные договора?
Вот если значение самого реквизита поменялось - тогда да, должно вытащится.
2(53) Просто сериализовывать не весь объект всект все-таки,  а почти весь - все кроме версии объекта. И тогда есть возможность сравнить текущую сериализацию с предыдущей, и если они равны, то значит объект не изменился, и мы откажемся от записи лишней версии.

(54) никак не отработает, события то не вызываются

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

(57)  не, глубины нет, 1 уровень, достаточно ж вытащить представление, чтобы показать документ 1 в 1 в том же виде, каким он когда-то был.

(59)
Но как по мне громоздко. При изменении одного реквизита делать копию всего объекта - как то неправильно. Да еще и контроля ссылочной целостности нет

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

2(61) громоздко с точки зрения занимаего места, с точки зрения кода как раз наоборот, все легко. Ну и да, контроля ссылочной целостности нет. Объект из базы исчезнет, а мы по прежнему сможем узнать кто что и когда в нем менял. Не ради этого ли все затевалось? :)

(62)  Во, так что ж сохраняется в это xml'e документа? Представления ссылочных реквизитов и ссылки на них?

2(64) я затрудняюсь классифицировать твой вопрос - он риторический или азбучный?
Посмотри во что сериализуется любой объект.

(65)  а, понял, погляжу, спасибо

(63)
Секунду. Если у нас изчезает объект, который пишеться в ведущее измерение(а в РС он ведущий), то разве записи с ним не пропадают?
Я говорил про то, что если удаляется значение реквизита(т.е. у ПТУ был контрагент1, стал контрагент2, а первого грохнули), то контроля целостности нет. Он здесь и не нужен, но в версии объекта будет фактически битаяя ссылка

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

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

2(67) Есть измерение Объект ведущее - исчезают. если нет, то нет

(16) ни что не мешает при перепроведении отключать это версионирование, а док РСВ не такой уж и большой, чтобы париться

как поубавилось кол-во пользователей, так необходимость в нем отпала, но отключать все равно не стал - мало ли чего