Какова лучшая стратегия для хранения данных журнала в базе данных?

Question

Я создаю приложение, которое требует обширной регистрации действий пользователей, платежей и т. Д.

Мне лучше с монолитной таблицей журналов и просто записывать ВСЕ в это .... или лучше иметь отдельные таблицы журналов для каждого типа действий? Я веду журнал (log_payment, log_logins, log_acc_changes)?

Например, в настоящее время я регистрирую взаимодействия пользователя с платежным шлюзом. Когда они подписываются на пробную версию, когда пробная версия становится подпиской, когда она перезагружается, возвращается, если произошел сбой или нет, и т. Д.

Я также хотел бы начать регистрировать действия или события, которые не взаимодействуют с платежным шлюзом (отмены продлений, запреты, сбои платежей, которые были перехвачены до того, как данные были даже отправлены на шлюз для проверки, входа в систему и т. Д.).

EDIT: Данные будут регулярно проверяться для проверки их целостности, так как на их основе людям нужно будет платить, поэтому точные данные очень важны. Запросы на чтение будут выполняться мной и двумя другими администраторами, поэтому в 99% случаев это будет запись / обновление.

Я только что подумал, что наличие нескольких таблиц просто создает больше точек отказа во время критических транзакций mysql, связанных со вставкой и обновлением данных платежа и т. Д.

Answer 1

При прочих равных условиях меньшие непересекающиеся таблицы могут иметь преимущество в производительности, особенно когда они тяжелые при записи (поскольку таблицы, связанные с журналами, могут быть) - большинство механизмов БД лучше настроены для работы в основном для чтения, редко написанные таблицы. С точки зрения написания (и обновления любых индексов, которые вам, возможно, придется поддерживать), небольшие непересекающиеся таблицы - явный выигрыш, особенно если есть какой-либо параллелизм (конечно, в зависимости от того, какой механизм вы используете для своих таблиц - это довольно важно рассмотрение в mysql! -).

С точки зрения чтения, все зависит от вашего шаблона запросов - какие запросы вам понадобятся и как часто. В некоторых случаях для такого шаблона использования, как вы упомянули, может быть некоторое преимущество в производительности при дублировании определенной информации, например если вам часто требуется текущая промежуточная общая сумма кредитов или дебетов пользователя, а также подробные проверяемые журналы того, как был получен промежуточный итог, сохранение (логически избыточной) таблицы промежуточных итогов по пользователям может быть гарантированно (а также прекрасно разделенные «таблицы журналов» о различных источниках кредитов и дебетов).

Answer 2

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

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

-

Для данной таблицы вы можете иметь таблицу table_history , которая имеет почти идентичную структуру, с пустыми полями, и первичный ключ, состоящий из двух частей (первичный ключ оригинальная таблица + последовательность). Если для каждой операции вставки или обновления вы записываете запись в эту таблицу, у вас есть полный журнал всего, что произошло с таблицей .

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

-

Кроме того, у вас может быть одна таблица журнала, в которой есть такие поля, как «таблица», «ключ», «дата», «кто», и связанная таблица, в которой хранятся измененные поля и значения.

Преимущество этого метода в том, что вы можете написать одну подпрограмму регистрации и использовать ее везде.

-

Я предлагаю вам оценить количество таблиц, потребности в производительности, изменить объем, а затем выбрать одну и пойти с ней.

Answer 3

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

С другой стороны, для целей контрольного журнала нет ничего лучше, чем иметь дублирующую таблицу для всех таблиц с каждым действием CRUD. Таким образом, каждая информация, занесенная в таблицу платежей или что-либо еще, будет занесена в вашу таблицу аудита.

Итак, ответ - оба.