Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
Ega23 © (2005-11-01 18:42:00)
Это не конкретный вопрос, а скорее попытка найти "идею".
Суть проблемы такова:
Есть некий "охраняемый объект". У этого охраняемого объекта есть чёткая логическая топология. Т.е. есть некоторое количество объектов класса "Территория", класса "Зона доступа", класса "Точка доступа" и класса "Точка контроля". Каждый объект имеет владельца (parent), т.е. по сути мы имеем дело с "деревянной" структурой.
Для всех инстансов объектов вводится сквозная идентификация (не может быть двух разных объектов с одинаковым ID).

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

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

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

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

Ega23 (2005-11-02 12:52:00) [1]

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

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

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

ANB (2005-11-02 11:17:00) [3]

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

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

Ega23 (2005-11-02 11:13:00) [4]

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

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

stone (2005-11-02 11:06:00) [5]

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

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

Ega23 (2005-11-02 10:48:00) [6]

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

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

Ega23 (2005-11-02 10:47:00) [7]

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

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

ANB (2005-11-02 10:46:00) [8]

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

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

Ega23 (2005-11-02 10:43:00) [9]

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

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

ANB (2005-11-02 10:40:00) [10]

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

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

stone (2005-11-02 10:40:00) [11]

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

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

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

Ega23 (2005-11-02 10:35:00) [13]

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

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

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

Ega23 (2005-11-02 10:16:00) [15]

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

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

Sergey13 (2005-11-02 10:11:00) [16]
Поддерживаю [1] и [3]. Чем меньше лог нуждается в чем либо - тем лучше. ИМХО.

Ega23 (2005-11-02 10:08:00) [17]

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

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

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

stone (2005-11-02 10:00:00) [18]

> Ega23 © (02.11.05 09:12)

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

Ega23 (2005-11-02 09:12:00) [19]

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

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

Ega23 (2005-11-02 09:10:00) [20]

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »