Одна таблица журнала по сравнению со столбцами журнала на каждой таблице
Я также был через эту боль - если запрос динамично сгенерирован (например, Будьте в спящем режиме Критерии), тогда я не мог бы найти практический способ сделать это.
хорошие новости для меня были то, что я только исследовал объединение для решения проблемы производительности при использовании 'или' в базе данных Oracle.
решение Patrick отправил (объединение результатов программно с помощью набора), в то время как ужасный (тем более, что я хотел сделать подкачку страниц результатов также) был достаточен для меня.
4 ответа
Единая таблица журнала может легко стать узким местом, если она будет записана в дополнение к любым другим операциям записи.
Вы также создадите дополнительный JOIN для некоторых запросов.
На мой взгляд, я не вижу преимуществ отдельной таблицы, кроме того, что остальные таблицы БД становятся немного «чище»
Один журнал - замечательная вещь.
В каждой таблице имейте столбец идентификатора только для целей ведения журнала. Назовите его LOG_ID или что-то в этом роде.
Каждый раз, когда вы выполняете INSERT, UPDATE или DELETE, он работает следующим образом.
INSERT запись журнала, получает присвоенный LOG_ID.
Выполните INSERT или UPDATE, установив LOG_ID внешним в измененной строке. Для DELETE у вас есть два варианта: фактически удалить строку или пометить строку как «неактивную», но не удалять ее. Этот второй вариант делает ваш журнал всех изменений полностью полным, но делает ваши таблицы довольно большими и медленными из-за неактивных строк, которые необходимо пропускать.
Зафиксировать.
Убедитесь, что ваш дизайн журнала может включать следующие виды информации .
Строка базы данных изменяется (Вставить, Обновить, Удалить). Изменения Insert и Update будут содержать ссылку FK на измененную строку. Обязательно укажите имя таблицы, чтобы прикладная программа могла правильно ее найти. Удаляемые изменения будут иметь только имя таблицы.
Другая информация об обработке, например запуск пакетного задания. Таким образом, вы можете регистрировать запуск / остановку и время выполнения пакетного задания, а также сохранять полную историю обработки.
Около 20 лет назад я узнал, что лучший способ справиться с такого рода информация просто вставляет в базу данных. Вы не должны изменять существующие записи и определенно не удалять какие-либо записи. По сути, вы будете хранить не сами данные, а их модификации. В результате у вас просто будет одна таблица, которая может делать все, что вы хотите, если бы у вас была достаточная скорость процессора / диска для просмотра всех данных и расчета данных на основе только этих вставок.
Сохранение только модификаций позволит вам вести полную историю всех ваших данных, позволяя вам быть чрезвычайно гибкими. По сути, вам понадобится только одна таблица, которая содержит все. Недостатком является то, что вам нужно выполнять гораздо больше вычислений и читать гораздо больше с диска, поэтому вам нужны уловки для ускорения процесса. Гибкость за счет производительности ...
В этом случае вы столкнетесь с аналогичной проблемой. К одной таблице будет обращаться все, что нужно для добавления или обновления записей. Это было бы вашим узким местом. Он по-прежнему хорош в однопользовательской среде, поскольку его будет использовать только один пользователь. В среде с низким числом пользователей он все еще может иметь очень хорошую производительность. Но если у вас более 250 пользователей, которые постоянно обращаются к этой таблице, это снизит общую производительность.
Кроме того, вы создадите проблему обслуживания, когда кто-то удалит записи. В таких случаях записи в этой таблице журнала также должны быть удалены.
Возвращает меня к тому, что я упоминал в начале ... Что вы можете сделать, так это объединить как таблицу истории, так и ваши обычные таблицы. Всякий раз, когда запись вставляется, изменяется или удаляется, вы должны добавлять запись в эту таблицу изменений, включая отметку времени и ссылку на пользователя. Это позволит сохранить историю ваших данных, и, как правило, вы будете выполнять только вставки в эту таблицу. Это все равно должно быть быстро. В качестве дополнительного бонуса вы можете воссоздать все содержимое своей базы данных, просто воспроизведя все действия в этой таблице модификаций, на всякий случай.
Вставки могут быть достаточно быстрыми, поэтому потеря производительности разумно небольшая, хотя это зависит от вашего реализация.
Но по каким-то причинам, узнав об использовании таблиц модификации,
мы обычно используем их в большинстве таблиц:
LastChgID int
LastChgDate datetime
иногда будет использовать, это в некоторых:
CreateID int
CreateDate datetime
LastChgID int
LastChgDate datetime
в других есть полная зеркальная таблица, где мы регистрируем каждый столбец с типом изменения флаг, дату и время и идентификатор пользователя.
Я бы держался подальше от таблицы, которую вы постоянно обновляете, просто добавляю столбцы, для этого и предназначена база данных, для хранения информации. У нас была таблица, которая увеличивалась (с обновлением) каждый раз, когда вызывалась хранимая процедура, и это была магнитная блокировка.
У нас есть общая таблица журнала, но она предназначена только для вставки и содержит информацию об отладке и ошибках. . Он не обновляется каждый раз, когда изменяется какая-либо строка, только когда разработчик решил что-то там написать, в основном несколько полей заголовка (идентификатор, дата и время, идентификатор пользователя, вызываемая процедура) с длинной отформатированной строкой, содержащей сообщение.