Проектирование БД: как обеспечить целостность

#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:

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

  • жить с этим ограничением, или
  • отбросьте это ссылочное ограничение.