Лог событий. Справочник или регистр сведений? #319594

День добрый. Есть вопрос. Задача: Нужно хранить в базе что-то вроде лога событий с произвольным количеством записей. Записи большой информационной ценности не представляют. Чило записей может быть довольно значительно. Как реализовать этот лог? 1. В виде справочника. Так, вроде как проще, да и проблем с количеством записей нет. 2. В виде Регистра сведений. Т.к. количество записей произвольно, то значит у регистра сведений должно быть измерение, которое представляло бы собой Число или строку (что нибудь вроде "НомерЗаписи"). Как лучше реализовать подобную задачу: в виде справоника или в виде регистра? На сколько неправильно использование подобного измерения в регистре?

Справочник - зло.(удаление объектов, контроль ссылочной целостности при ТИИ) Регистр сведений - лучше, но тоже не гуд. Внешний dbf и работа через Xbase? Текстовый файл?

Обычно все логи в текстовый файл и пишутся.Зачем изобретать велосипед?

если регистр, то поля не ссылочного типа. Чтоб ТИИ на нём не спотыкалось ))

Для текстового файла индексацию сам строить будет? Весщь геморойная. В Xbase это уже есть. В регистре сведений тоже, но он в базе...

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

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

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

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

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

Жёско.

Сами сообщения плана обмена там не хранятся, только история.

База под терминалом?

я вместо этой истории храню в отдельной папке сами сообщения. Они же - и история. Куда практичнее

Если под терминалом - то могу вообще предложить чудовищную весщь. Довериться Microsoft-у. Хранить в журнале событий. Не знаю не плюсов, не минусов. Просто альтернатива. ;-)

Да Пользователям зачастую желательно знать также историю проверки наличия сообщений.

Журнал событий это слишком сурово.

Реальные пацаны 1С не ищут легких путей.

историю _проверки_ ??? а не пошли бы они ? ужос сделай им проверку каждые 30 секунд пусть подавятся

самое лучшее - делать запись в журнал регистрации. Он для этого и предназначен.

История проверки хороша тем, что она устраняет вопросы вроде ("Почему нет обмена? Где продажи за вчера?!"). Пользователь сам может убедиться, что обмен работает, просто с другого узла не отправили сообщения. Кстати сообщения от разных узлов могут храниться в разных каталогах или компах. Всё-таки есть ли смысл переделывать справочник в регистр сведений? Я так понял ссылки из записей в любом случае надо убрать?

А можно по человечески получить данные обратно из журнала регистрации для вывода в форму?

Up!

пока только вижу ВыгрузитьЖурналРегистрации. Наверно, это не очень удобно. ВыгрузитьЖурналРегистрации(<Имя выходного файла>, <Фильтр>, <Колонки>, <Имя входного файла>) Параметры: <Имя выходного файла> (обязательный) Тип: Строка. Строка, содержащая имя выходного XML файла. <Фильтр> (необязательный) Тип: Структура. Структура фильтра журнала регистрации и условия сравнения: ДатаНачала(StartDate) - Дата, Если задана на больше или равно. Значение по умолчанию Неопределено; ДатаОкончания(EndDate) - Дата, Если задана на меньше или равно. Значение по умолчанию Неопределено; Уровень(Level) - УровеньЖурналаРегистрации или массив уровней, Равенство, если массив, то в списке. Значение по умолчанию Неопределено; ИмяПриложения(ApplicationName) - Строка или массив строк, Равенство, если массив, то в списке. Значение по умолчанию Неопределено; Пользователь(User) - ПользовательИнформационнойБазы или массив пользователей. Равенство, если массив, то в списке. Значение по умолчанию Неопределено; Компьютер(Computer) - Строка или массив строк, Равенство, если массив, то в списке. Значение по умолчанию Неопределено; Событие(Event) - Строка или массив строк, Равенство, если массив, то в списке. Значение по умолчанию Неопределено; Метаданные(Metadata) - ОбъектМетаданных или их массив. Равенство, если массив, то в списке. Значение по умолчанию Неопределено; Данные(Data) - Значение, тип значения – ссылка на объект (СправочникСсылка и т.д.), Равенство. Значение по умолчанию Неопределено; ПредставлениеДанных(DataPresentation) - Строка. Содержит; Комментарий(Comment) - Строка. Содержит. <Колонки> (необязательный) Тип: Строка. Для выгрузки в XML формате доступны следующие колонки: Уровень(Level); ПредставлениеМетаданных(MetadataPresentation) Для того, чтобы выгрузить определенные колонки журнала регистрации необходимо перечислить их имена, при этом необходимо имя каждой колонки отделять запятой. <Имя входного файла> (необязательный) Тип: Строка. Строка, содержащая имя входного файла. Описание: Позволяет выгрузить журнал регистрации в XML формате. Существует возможность установить фильтр, задаваемый структурой специального формата, указывающий, какие записи журнала регистрации выгружать, а также указать колонки, которые необходимо выгружать. Если указано имя входного файла, то происходит выгрузка из указанного файла.