Лучший дизайн логирования или немного магии SQL?

Question

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

Sarah added a user, slick101
Mike deleted a user, slick101
Bob edited a service, Payment

Разбивается так:

Sarah [user_id] added a user [message], slick101 [reference_id, reference_table_name]

В таблицу, подобную этой:

log
---
id
user_id
reference_id
reference_table_name
message

Обратите внимание, что сообщения "Bob" и "Payment" в приведенных выше примерах являются идентификаторами других таблиц, а не фактическими именами. Для получения имен необходимо объединение.

Похоже, что "имя_ссылки _ таблицы _" предназначено для поиска правильных имен в правильной таблице, поскольку хранится только идентификатор _ ссылки. Вероятно, было бы хорошо, если бы я мог как-то присоединиться к имени таблицы, которое хранится в reference_table_name, например:

select * from log l
join {{reference_table_name}} r on r.id = l.reference_id

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

Есть ли лучший способ или можно как-то сделать воображаемое объединение?

Приветствия

Answer 1

Чтобы получить объединение на основе моделирования, вы должны рассмотреть двухэтапный процесс:

1. Получить имя таблицы из LOG для определенного сообщения

2. Используйте динамический SQL, создавая фактический запрос в виде строки. IE:

   "SELECT l. * FROM LOG l JOIN" + tableName + "r ON r.id = l.reference_id"

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

Сколько истории нужно приложению?

Вам нужно знать, ктосделал то, что для значения месяцев / лет в прошлом? Если записи необходимы, они должны быть заархивированы и удалены из таблицы. Если вам не нужна вся история, рассмотрите возможность использования следующих столбцов аудита в каждой таблице:

• ENTRY_USERID, NOT NULL
• ENTRY_TIMESTAMP, DATE, NOT NULL
• UPDATE_USERID, NOT NULL
• UPDATE_TIMESTAMP, DATE, NOT NULL

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