Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2005.12.18;
Скачать: [xml.tar.bz2];

Вниз

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

 
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]


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

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


 
Ega23 ©   (2005-11-02 10:47) [18]


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


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


 
Ega23 ©   (2005-11-02 10:48) [19]


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


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


 
stone ©   (2005-11-02 11:06) [20]


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

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


 
Ega23 ©   (2005-11-02 11:13) [21]


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


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


 
ANB ©   (2005-11-02 11:17) [22]


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

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


 
Sergey13 ©   (2005-11-02 11:25) [23]

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


 
Ega23 ©   (2005-11-02 12:52) [24]


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


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



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2005.12.18;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.52 MB
Время: 0.014 c
1-1132889105
beglec
2005-11-25 06:25
2005.12.18
Как загрузить банер в программу?


3-1130932336
Mouse_Rat
2005-11-02 14:52
2005.12.18
Импорт данных из файла в FireBird


1-1132809968
john_mag
2005-11-24 08:26
2005.12.18
OleContainer


10-1109556397
msgipss
2005-02-28 05:06
2005.12.18
Создание надстройки над Excell


1-1132302096
Некто_Аполло
2005-11-18 11:21
2005.12.18
Момент максимизации окна





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский