Проблемы логгирования данных

← →
Ega23 © (2005-11-01 18:42) [0]

Это не конкретный вопрос, а скорее попытка найти "идею".
Суть проблемы такова:
Есть некий "охраняемый объект". У этого охраняемого объекта есть чёткая логическая топология. Т.е. есть некоторое количество объектов класса "Территория", класса "Зона доступа", класса "Точка доступа" и класса "Точка контроля". Каждый объект имеет владельца (parent), т.е. по сути мы имеем дело с "деревянной" структурой.
Для всех инстансов объектов вводится сквозная идентификация (не может быть двух разных объектов с одинаковым ID).

По требованиям к системе, изменения состояний данных объектов (тревога, неисправность и т.п.) должны обязательно протоколироваться и протокол должен хранится как минимум год.
В связи с этим возникает проблема: если протокольную таблицу создать строго нормализованной, то нельзя будет удалить объект из системы (как минимум год).

Собственно ищется некое решение данной проблемы. Вариантов тут масса (на вскидку - маскирование объектов).

Хотелось бы выслушать разные мнения. Можно ссылки на статьи по данному вопросу.

Заранее спасибо всем откликнувшимся.

← →
Val © (2005-11-01 18:53) [1]

не держать в логах внешних ключей

← →
Ega23 © (2005-11-01 18:55) [2]

> не держать в логах внешних ключей

Это не избавит от проблемы. Где брать описание удалённого объекта?

← →
Val © (2005-11-01 18:56) [3]

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

← →
Виталий Панасенко (2005-11-02 09:07) [4]

http://www.delphiplus.org/articles/ib/db_log/index.html - для FB/IB правда...и в тему ли...:-)))

← →
Ega23 © (2005-11-02 09:10) [5]

> Виталий Панасенко (02.11.05 09:07) [4]

Спасибо, почитаю.

← →
Ega23 © (2005-11-02 09:12) [6]

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

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

← →
stone © (2005-11-02 10:00) [7]

> Ega23 © (02.11.05 09:12)

Эти события уникальны? А их описания?

← →
Ega23 © (2005-11-02 10:08) [8]

> Эти события уникальны? А их описания?

Так описания-то не событий, а объекта теряются.
Грубо говоря, схема такая.

create table Events ( GUID uniqueidentifier not null, ObjID int null, StateID int null, DateIn datetime not null, constraint PK_EVENTS primary key (GUID) ) go /*==============================================================*/ /* Table: Objects */ /*==============================================================*/ create table Objects ( ObjID int not null, StateID int null, ObjName varchar(64) not null, constraint PK_OBJECTS primary key (ObjID) ) go /*==============================================================*/ /* Table: States */ /*==============================================================*/ create table States ( StateID int not null, StateName varchar(64) not null, constraint PK_STATES primary key (StateID) ) go alter table Events add constraint FK_EVENTS_REFERENCE_OBJECTS foreign key (ObjID) references Objects (ObjID) go alter table Events add constraint FK_EVENTS_REFERENCE_STATES foreign key (StateID) references States (StateID) go alter table Objects add constraint FK_OBJECTS_REFERENCE_STATES foreign key (StateID) references States (StateID) go

На каждое оперативное изменение состояния объекта должна присутствовать запись в Events

← →
Sergey13 © (2005-11-02 10:11) [9]

Поддерживаю [1] и [3]. Чем меньше лог нуждается в чем либо - тем лучше. ИМХО.

← →
Ega23 © (2005-11-02 10:16) [10]

> Sergey13 © (02.11.05 10:11) [9]

Большой он, сволочь, будет. Да и поток событий не маленький ожидается.

← →
Val © (2005-11-02 10:27) [11]

>Ega23 © (02.11.05 10:16)
"хочу чтоб все было и мне за это ничего не было?" :) логировать хотим побольше, а места выделять поменьше - интересно у вас получается :)

← →
Ega23 © (2005-11-02 10:35) [12]

> "хочу чтоб все было и мне за это ничего не было?" :) логировать
> хотим побольше, а места выделять поменьше - интересно у
> вас получается :)

Я не настолько глуп, чтобы самому дойти до тривиального решения. Речь как раз о не тривиальном идёт. Поэтому сюда и запостил.

← →
Sergey13 © (2005-11-02 10:36) [13]

2[10] Ega23 © (02.11.05 10:16)
> Большой он, сволочь, будет. Да и поток событий не маленький ожидается.
А дисковая память сейчас сильно дорогая что-ли? 8-)
Если что-то серьезное, то ИМХО вообще стОит дублировать лог в текстовый файл, что-бы и от БД не зависеть при просмотре. Мало ли там чего - тьфу три раза. 8-)
Можно подумать о скидывании лога за месяц (например) в отдельное место. Т.е. разделить логи на активные и архивные.

← →
stone © (2005-11-02 10:40) [14]

> На каждое оперативное изменение состояния объекта должна
> присутствовать запись в Events

И что тебя смущает? Или из таблиц Objects или States могут случайно пропасть записи?

← →
ANB © (2005-11-02 10:40) [15]

> Ega23 © (02.11.05 10:16) [10]
>
> > Sergey13 © (02.11.05 10:11) [9]
>
>
> Большой он, сволочь, будет. Да и поток событий не маленький
> ожидается.

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

← →
Ega23 © (2005-11-02 10:43) [16]

> Можно подумать о скидывании лога за месяц (например) в отдельное
> место. Т.е. разделить логи на активные и архивные.

Это не избавляет от того, что будет много места.
Если ты обратил внимание, я наверху писал, что структура объекта - "деревянная". Если я храню в таблице событий только ObjID, то при просмотре я могу всю его подноготную вытащить - от корня до листа. Прикинь, то же самое для каждого объекта строкой в протокол фигачить?

← →
ANB © (2005-11-02 10:46) [17]

> что структура объекта - "деревянная".

Эх, это бы на оракле делать то. Опять таки ИМХО.

> Заведи таблицу логирования самих объектов. И поддерживай
> при добавлении и изменении основной таблицы (триггером).
> При удалении объекта в основной можно помечать в логирующей
> объект как удаленный. Все равно денормализация, но тогда
> в таблице событий не надо будет хранить всю инфу о самих
> объектах. Ссылку из нее сделай, ессно, на лог объектов.
> Все имхо.

Любопытно. Подумаю в этом направлении.

> И что тебя смущает? Или из таблиц Objects или States могут
> случайно пропасть записи?

Они могут быть целенаправлено удалены.

> Ega23 © (02.11.05 10:48) [19]
>
> > И что тебя смущает? Или из таблиц Objects или States могут
>
> > случайно пропасть записи?
>
>
> Они могут быть целенаправлено удалены.

ИМХО, это не есть правильно. Лучше уж добавить в эти таблицы битовое поле типа "статус" действует/не действует

> ИМХО, это не есть правильно. Лучше уж добавить в эти таблицы
> битовое поле типа "статус" действует/не действует

Ну я это ещё в [0] писал (маскирование объектов).
Хотелось ещё версий. Если эта окажется оптимальной - на ней и остановлюсь.

> Ega23 © (02.11.05 11:13) [21]

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

2[21] Ega23 © (02.11.05 11:13)
Еще одна проблема маскирования. Если ты "маскируешь" головной объект - куда девать детей? Понятно, что надо на это реагировать. Вот только контроль за целостностью уже уходит из простых констрейнтов в код. А это снижение надежности.

> Еще одна проблема маскирования. Если ты "маскируешь" головной
> объект - куда девать детей? Понятно, что надо на это реагировать.
> Вот только контроль за целостностью уже уходит из простых
> констрейнтов в код. А это снижение надежности.

Об этом и речь.

Проблемы логгирования данных Найти похожие ветки