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

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

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

Отслеживание изменений в базе [D6, Firebird 2.0]

Страницы: 1 2 >
Sirus © (2007-11-03 08:31:00)
Привет Мастера!
Есть вопрос: Как можно реализовать отслеживание изменений в базе данных? Отслеживаться должны изменение, удаление и вставка записи в базу данных. При этом нужно еще хранить код пользователя проделавшего эти изменения.

Есть какие-нить соображения или наработки, поделитесь опытом.

Sergey Masloff (2007-11-28 21:09:00) [1]
Petr V. Abramov © (28.11.07 11:25) [36]
>это все так, пока транзакции, в которых происходит логирование, не >начинают биться за какой-нить ресурс.
Так оно же в той же транзакции что и изменение данных. И как раз в нем ничего военного нет - просто прямая запись. Мизерная нагрузка по сравнению с собственно редактированием. На таблицах логов естественно никаких ключей и так далее. Не за что там конкурировать

Sergey Masloff (2007-11-28 21:06:00) [2]
Andrey © (28.11.07 10:05) [35]
В данный момент это база с 4500 пользователей объемом 0.6 терабайт и ростом впримерно в 20 Гб в неделю. Расходы на полное логгирование - пара-тройка процентов ресурсов сервера. Все ходы записаны.

Desdechado (2007-11-28 11:52:00) [3]
> Sergey Masloff (27.11.07 22:58) [34]
Не совсем так.
Если логирование ведется один-в-один, то да - сдублировать запись проблемы нет. А вот если приходится расшифровывать кучу внешних ключей из справочников, то изменение одной записи приводит к множеству дополнительных чтений, а это уже не фигня.

Petr V. Abramov (2007-11-28 11:25:00) [4]
> Sergey Masloff (27.11.07 22:58) [34]
это все так, пока транзакции, в которых происходит логирование, не начинают биться за какой-нить ресурс. И вот тут совсем небольшое уменьшение скорости работы продавщицы (время транзакции) может начать заметно увеличивать длину очереди

Andrey (2007-11-28 10:05:00) [5]
>Sergey Masloff (27.11.07 22:58) [34]
Хм... базы разные бывают )
Бывают базы на CD, в которые запись возможна только чисто теоретически.
Бывают базы хранящие статистику разных датчиков пишущююся посекундно и выдающие оператору отчет раз в сутки.
Бывают разные наколенные блининги которые в MySQL базейку заливают весь NetFlow (свят-свят-свят), а потом один раз его считывают и агрегируют, расчитывают всякие разности, делают отчеты... такой себе цыкл жизни записи: insert -> select -> to_archiv

А вот про скорость работы, это вы зря ) Логирование на тригерах хорошо подгружает сервер при редактировании данных. Конечно если в базе 3 таблички по 100 записей, а машинка какой-нибудь там коре-два-дуо-и-еще-раз-дуо, то на глаз разницы не увидишь. Я раньше тестировал свои подел на пеньке 133. Вот там очень(!) хорошо видно любое бутылочное горлышко... и иногда даже бутылочное донышко )

Sergey Masloff (2007-11-27 22:58:00) [6]
Вставлю свои 5 копеек.
1. По моим наблюдениям (это не прикидки а статистические замеры на реальных базах) доля модифицирующих операций конечно не 1% но практически редко превышает 5%

2. Вот на скорость работы базы фактически write-only таблица лога не повлияет вообще никак. А диски сейчас дешевые так что если лог нужен то пиши спокойно и не парься.

StriderMan (2007-11-27 14:46:00) [7]
Удалено модератором

Sergey13 (2007-11-27 14:34:00) [8]
> [31] StriderMan (27.11.07 14:15)

1. Нафига поднимать чужойтопик трехнедельной давности?
2. То, что это работает на порядки быстрее логирования понятно. Непонятно как это относится к логированию.

StriderMan (2007-11-27 14:15:00) [9]
Удалено модератором

Anatoly Podgoretsky (2007-11-07 15:48:00) [10]
Нашли общую точку соприкосновения.

Sergey13 (2007-11-07 15:21:00) [11]
> [28] Anatoly Podgoretsky © (07.11.07 14:27)

Так и я про это толкую. 8-)

Anatoly Podgoretsky (2007-11-07 14:27:00) [12]
Оператор это не база.

Sergey13 (2007-11-07 13:24:00) [13]
> [26] Anatoly Podgoretsky © (07.11.07 09:14)

Я тебе про Фому, а ты мне про Ерему.
Оператор на складе меняет информацию?

ЗЫ: Разговор переместился в сторону от вопроса, ИМХО. Стоит ли продолжать?

Anatoly Podgoretsky (2007-11-07 09:14:00) [14]
> Sergey13 (07.11.2007 09:01:25) [25]

Таких баз, в которых чаще меняют, чем читают почти нет

Sergey13 (2007-11-07 09:01:00) [15]
> [24] Anatoly Podgoretsky © (07.11.07 08:54)

> В большинстве баз...
> ...например Интерпола.

Ты думаешь автор топика пишет для Интерпола или ЮНЕСКО с ООН? Сомневаюсь.
Мне кажется он пишет очередной склад/бухгалтерию/документооборот, в которой все таки меняют инфу чаще. 8-)
Для меня например подобные БД являются более "типовыми".

Anatoly Podgoretsky (2007-11-07 08:54:00) [16]
> Sergey13 (07.11.2007 08:44:23) [23]

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

Sergey13 (2007-11-07 08:44:00) [17]
> [16] Anatoly Podgoretsky © (06.11.07 19:21)

Твои слова, ИМХО, никак не противоречат моим. Понятно, что читающих запросов в БД на порядки больше чем модифицирующих, но работа пользователей (а не сервера) все таки в основном состоит из модификации информации, а не из наблюдения за ней в "типовой" БД.

stud (2007-11-07 08:25:00) [18]
Anatoly Podgoretsky © (06.11.07 20:50) [21]
Хорошее железо залог успеха.

хорошее железо развращает программистов)))

Anatoly Podgoretsky © (06.11.07 19:19) [15]
Объем равен = количество изменений одной записи + дополнительная информация по записи.

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

Anatoly Podgoretsky © (06.11.07 19:23) [18]
Боятся :-)
ишо как!!) пару раз разбор устраивали, тем более что с деньгами дело связано было. почемуто потом перестали паролями обмениваться))

Anatoly Podgoretsky (2007-11-06 20:50:00) [19]
> PEAKTOP (06.11.2007 20:04:20) [20]

Да я не возражаю, возражение не от меня было.
А то что упор на диски был не убедителен.
Диски становятся определяющим фактором при нехватке оперативной памяти, но тут уже надо подумать об переходе на 64 бита и наращивание до предела, например до 128 гб. Но и это может оказаться недостаточным для террабайтных баз с большой нагрузкой тогда SAN то 10 гб оптике с мультичанел.

Хорошее железо залог успеха.

PEAKTOP (2007-11-06 20:04:00) [20]
> Anatoly Podgoretsky © (06.11.07 19:22) [17]
> а сервер постоянно пашет.

С ума сойти... а что он еще делать должен ? :)

> Anatoly Podgoretsky © (06.11.07 19:25) [19]
> но на MSSQL нет проблем, и не тольно в другой БД, но и на другой сервер, на другой машине.

На Firebird тоже, если через UDF. Но это решение задачи по пути "истинного проктолога", ИМХО.
Гораздо кошернее решать ее через железо. 4Гб база данных (60% - логи) ? - ну и фиг с ней ! Работает.

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

Наверх

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