#mysql #database #database-design
#mysql #База данных #проектирование базы данных
Вопрос:
Предположим, я хочу зарегистрировать определенные вещи в журнале действий в моей базе данных. В некоторых случаях эти действия связаны с пользователем (например, пользователь что-то создал). В некоторых случаях эти действия автоматически выполняются приложением (например, система по какой-то причине обновила какую-то запись). Я хочу иметь возможность отслеживать, кто и что делал в системе. Отслеживание того, что делают пользователи, кажется простым:
TABLE: user
- user_id (PK)
TABLE: activity_log
- activity_log_id (PK)
- user_id (FK)
Приведенный выше дизайн позволяет мне связывать каждое действие с конкретным пользователем (и, таким образом, обеспечивать ссылочную целостность). Однако, что, если это система, которая приняла меры? В нем нет, который user_id
я могу вставить в activity_log
.
Должен ли я:
- Просто вставьте, скажем,
0
какactivity_log.user_id
представлять систему, даже если0
она не существует вuser
таблице? InnoDB не позволит мне этого сделать, верно? - Создайте пользователя специально для представления системы. Проблема в том, что каждому владельцу учетной записи в моем приложении может потребоваться собственный «системный пользователь», чтобы я мог позже отличить системного пользователя одной учетной записи от системного пользователя другой учетной записи. Возможно, это может стать уродливым. Не уверен.
Предложения?
Ответ №1:
Вы могли бы разрешить вашему activity_log.user_id
содержать нули, тогда НУЛЬ будет указывать на то, что ни один пользователь не выполнил действие, а «ни один пользователь» означает «система это сделала».
Если вы не хотите использовать NULL, чтобы указать, что «система сделала это», тогда вы можете добавить пользователя в свою таблицу users и использовать этого пользователя в качестве заполнителя для «система сделала это».
Комментарии:
1. Я не вижу разницы между использованием
0
илиNULL
. Проблема в том, что ссылочная целостность не может быть обеспечена, верно?2. @StackOverflowNewbie: у вас может быть NULL в столбце, который является FK, но у вас не может быть ненулевого значения, которого нет в таблице, на которую ссылается.
Ответ №2:
Одна из проблем обеспечения ссылочной целостности в приложениях ведения журнала и аудита заключается в том, что вы не можете удалить пользователя. (Или что бы вы ни проверяли.) Вы можете привести веские аргументы в обоих случаях,
- жить с этим ограничением, или
- отбросьте это ссылочное ограничение.