Реляционный пурист сказал бы, что каждое отдельное событие - это его собственная сущность.Похоже, вы уже наполовину следите за этой моделью (с таблицей для каждого типа). Родительская таблица events
на практике мало что добавляет.Вы не можете UNION
строки из таблиц, которые имеют разные схемы и "перегруженные" внешние ключи, почти всегда неприятны.
Чаще всего я видел эти таблицы "событий", объединенные в одну таблицу "журналов".Становится намного проще скомпилировать все события и представить их в приложении.Исторически различные атрибуты зарегистрированных событий выражались в виде свободного текстового поля, которое содержало дополнительную информацию, но я хотел бы предположить, что это было бы хорошим использованием для типа данных XML.
В результате вы получили бы такую таблицу событий, как эта:
CREATE TABLE events
(
Event_num int,
event_date datetime,
user_id int,
... //other attributes common to all events
event_data XMLTYPE
)
Это позволяет консолидировать все ваши данные в одной таблице, в то же время позволяя использовать разные атрибуты для разных событий.Это один из наиболее распространенных вариантов использования XML в реляционной БД, который является усовершенствованием более старого метода хранения данных журнала событий.