Задача стоит аналогично КПП  - есть объекты, их состояние, и история - когда менялось, чтобы можно было отчет посмотреть.
как лучше реализовать с учетом того что событий много, историю надо хранить задолго, а тормоза - крайне нежелательны?
база на SQL.
периодический реквизит вызывает сомнение.
для регистра понадобится документ городить.
вспомнил про регистры сведений, но на 8ку пока не перейти)
может еще как то иначе сделать?
тут много зубров по 7ке наверняка и подобный опыт есть - поделитесь, как бы вы сделали.

(0) ну как вариант, в течении дня пишешь в документ, в шапке Объект, в таб.части что менялось...
ночью выгружаешь в SQL, документы удаляешь или очищаешь таб.часть...

(1) не совсем понял смысл хранения в промежуточном документе который потом удалится?

Отдельная (от 1С) база и табличка. Прямые запросы.

(0) Табличку заведи. Или текстовый файл.

Если в сетке видима база СКУДа, то прямо к ней запросы и строить.

Если все же внутри - служебный справочник.

(4) во что превратится текстовый файл за скажем 5 лет, и как в нем искать данные по миллионам событий? это совсем странный вариант.
(5) это не скуд, отдельная задача, просто близка очень по смыслу.
(3) это пожалуй лучший вариант пока.

(2) чтобы в момент записи объекта не лезть в какие-то внешние соединения....

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

(7) Отдельная база + триггеры на запись. Триггер проверять/создавать при началеРаботыСистемы. Тогда ничего в самой 1С кроме процедурки генерации триггера и не надо будет.

(7) Запись в файл - наименее тормозной вариант.
Анализировать это добро и потом можно, много всяких инструментов есть. Да хоть бы и переписывать в SQL-табличку по ночам.
Плюс за файловый лог, это то, что в него внутри транзакции можно писать. Записи в SQL-табличку откатятся вместе с транзакцией.

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

(12) Если основной отбор будет по индексируемой дате, то размер справочника тебя особенно беспокоить не будет.

(10) У нас тут героические админы как-то раз так сделали. Это было прикольно. Хорошо их рядом не было, когда я понял, что произошло. Убил бы, ей богу.

(12) Короче, если типовые запросы будут иметь приемлемую селективность по индексируемым полям, то размеры таблиц особого влияния на производительность оказывать не будут. Это как бы основная идея проектирования СУБД.

(10) а можно чуть подробнее? с триггерами не работал.
(13) то есть добавить справочник событий с отбором по дате, событием, объектом, временем.

Ну, т.е. будут конечно, но кривая будет очень пологая.

(16) Вспоминая проблемы 7.7 с датой-временем, я бы их тупо зафигачил в наименование справочника в формате "ГГГГММДД ЧЧ:мм:сс"

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

Какое количество пользователей работает онлайн?

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

ночью эти данные переносил в базу SQL с очисткой таб.части

Отчеты строить по умолчанию - по данным SQL базы (или в зависимости от периода отчета)...

Тригеры не вариант - нужно будет постоянно следить за добавление/изменением/удалением реквизитов.
Поскольку база SQL - оптимальный вариант - хранение в справочниках истории.

(20) 30+/- плюс всяческие регламентные обмены.

С прямыми запросами как?

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

делал когда то, хранил в отдельной табличке
http://pics.rsh.ru/img/_htgo09q3.png

+21 почему не справочник....
1. получить изменения по объекту можно просто выгрузить в ТЗ таб.часть документа, который указан в реквизите vs ВыбратьЭлементыПоРеквизиту и цикл с заполнением...
2. удаление истории: очистка таб.части vs цикл по элементам справочника с непосредственным удалением...

и т.д.

а в снеговике, иногда не хватает вот этого
http://catalog.mista.ru/public/20038/

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

1. Чтобы избежать конфликта блокировок при одновременной записи изменений разными пользователями - пиши изменения в текстовый файл с генерацией уникального имени в файл. Ночью файлы обрабатывай и пиши в справочник с последующим удалением обработанных файлов.
2. Я делал два справочника - один просто как таблица - Дата|Время|Пользователь|ТипОбъекта|ВидОбъекта|ИзменениеОбъекта(Справочник), второй справочник - ИзменениеОбъекта, где уже хранится история изменения объекта.

(28) Почему не хватает? Версионирование же?

(29) во всех критических объектах всегда делаю реквизиты Автор, ДатаСоздания, Редактор, ДатаРедактирования...
и все говорю: последний записал - принял на себя все риски по содержимому ))

(28) А, сорри. Невнимателен.

(28) Но по-идее, реализовать же можно и значительно проще, чем в 7.7

(26) что насчет справочника с историей состояния скажешь, с отбором на дату? то что фишер советует?

(34) ну..как то лень пересиливает.
Надо будет заняться что, ле на досуге.
Иногда полезно:

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

(32) Примерно так, так и было - кто последний тот и папа, но они еще писали пояснение -зачем они туда лезут для редактирования, а вот если пояснения не было - сразу депримирование, еще  помню делали большой пул для копий БД, откуда можно было сравнить изменения

(35) да пофик где хранить то, хоть тупо строка и значениВСтроку\ЗначениеВСтрокуВнутр..

Как показала практика, особа вся эта инфа с версионированием (что в 7.7, что в снеговике) особо то и не нужна, ну так, информации для.
Ну выяснили , что месяц назад где-то кто-то что-то изменил ..дальше то что ? Поезд ушел :)
Если только не явная диверсия, то, на эту инфу можно забить.
Единственное, если в один документ вносят изменения несколько юзверей на разных этапах, добавляя в него новую инфу, можно посмотреть цепочку редактирований..усё

В снеговике, частая операция в обслуживании базы - прибитие устаревшей инфы в регистре версииобъектов, чтоб не пух :)

Ибо смотреть, что там было полгода назад, никто уже не будет

(41) у меня к сожалению смотреть будут и на то что было 3 года назад тоже)

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