Разумно ли иметь таблицу, которая не ссылается ни на одну другую в дизайне базы данных?

Question

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

• Сотрудники - таблица, содержащая все данные о сотрудниках
• Пользователи - таблица, содержащая сотрудников, которые имеют имя пользователя и пароль для доступа к программному обеспечению
• UserLog - таблица для отслеживания входа и выхода пользователей из системы и расчета время на программное обеспечение

В этом случае, если сотрудник покидает компанию, я также хочу убедиться, что я удалил их из таблицы Users, чтобы они больше не могли получить доступ к программному обеспечению. Я могу добиться этого, используя ON DELETE CASCADE как часть отношения FK между EmployeeID в Employees и Users.

Однако я не хочу удалять их данные из UserLog, так как мне интересно собирать данные о том, сколько времени люди тратят на программное обеспечение, и тот факт, что они больше не работают в компании, не означает, что их пользователь поведение больше не актуально.

У меня остается таблица UserLog, которая не связана с другими таблицами в моей базе данных. Это разумная идея?

Просматривая книги и т. Д. / Googled в Интернете, я не сталкивался ни с какими схемами БД с таблицами, которые не имеют отношений с другими, и поэтому мой инстинктивный инстинкт здесь говорит о том, что мой подход не надежен ...

Буду признателен за руководство, пожалуйста.

Answer 1

В этом случае я бы предпочел «мягко удалить» сотрудника, добавив столбец «DeletedDate» в таблицу «Сотрудники». Это позволит вам поддерживать ссылочную целостность с вашей таблицей UserLog, и все детали всех сотрудников, прошлых и настоящих, останутся доступными в базе данных.

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

Answer 2

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

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

Кстати, я бы не рекомендовал удалять пользователей из таблиц.Возможно, на них есть какой-то бит IsActive или IsDeleted, который бы эффективно закрывал их от приложения, но по возможности следует избегать удаления.

Answer 3

Это разумная идея

Проблема заключается в следующем.Так как данные не связаны, вы можете удалить что-то из таблицы сотрудников и по-прежнему иметь ссылки в UserLog.После удаления информации о сотруднике у вас нет возможности узнать, с чем связаны данные журнала.Это нормально?Технически да.Ничто не мешает вам сделать это, но тогда почему вы храните данные в первую очередь?Вы также не можете гарантировать, что данные в таблице на самом деле относятся к сотруднику.Кто-то может случайно ввести неверный EmployeeID в таблицу, которая никому не принадлежит.Ключи помогают предотвратить повреждение данных.Всегда лучше иметь дополнительные данные, чем плохие.

Я обнаружил, что вы никогда не хотите удалять данные, когда это возможно.Пространство дешево, и вы можете добавить флаги и т. Д., Чтобы показать, что запись не активна.Да, это требует больше работы (это можно быстро исправить, создав представление, отображающее только активных сотрудников) и сказав, что вы никогда не должны удалять данные, которые извлекаются далеко, но вы начинаете связывать данные вместе.Удаление становится очень сложным.Если вы не добавляете FK просто для того, чтобы удалять записи, это говорит о том, что вам нужно пересмотреть свою стратегию.

Использование Cascade Delete также может быть очень опасным.Модель, которую вы заявляете, заключается в том, что в любое время, когда вы не хотите удалять данные, вы должны знать, чтобы не добавлять FK в эту таблицу, которая связывает ее с пользователями.Это не займет много времени, чтобы забыть об этом.

Answer 4

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

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

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

Answer 5

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

Answer 6

Что вы можете сделать, это использовать логическое удаление или отключение пользователя, добавив значение bool Deleted или Disabled в таблицу Users.

Или замените EmployeeId на имя сотрудника в UserLog.*

Answer 7

IANADBA, но обычно считается очень плохой практикой удалять практически что-либо из БД. Было бы намного лучше иметь какой-нибудь заблокированный флаг / «удаленную» метку даты в таблице пользователей и сохранить свой FK.

Answer 8

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

Одна вещь, которую я замечаю, это то, что вы используете EmployeeID в журнале, но не используете его как внешний ключ к вашей таблице Employee. Я понимаю, почему вы этого не хотите, потому что вы будете увольнять сотрудников. Но если вы отбрасываете их полностью, то столбец EmployeeID не имеет смысла.

Решением этой проблемы было бы сохранение флага для сотрудников, например active, который отслеживает, активны они или нет. Таким образом, данные журнала имеют смысл.

Answer 9

Разумные?Конечно, в этом есть смысл, так как вы описали необходимость держать этих пользователей на неопределенный срок.Проблема, с которой вы столкнетесь, - это поддержка таблиц.Вместо того чтобы делать каскадное обновление один раз, вам нужно будет использовать как минимум два обновления для вставки нового пользователя.