Лучше ли отслеживать события в отдельных моделях или в одной модели событий?

Question

Я понимаю, что этот вопрос является общим, но я думаю, что люди с большим опытом в отслеживании событий будут иметь хорошее понимание.

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

1) Создайте модель с именем AssetDownload и заполните ее данными.
2) Создайте модель под названием «Событие» или «Активность» и сделайте ее общей моделью для отслеживания событий.

Вижу следующие плюсы и минусы:

Метод 1:

• Pro - Лучшая читаемость, потому что Модель представляет собой событие точно
• Pro - не нужно будет проводить рефакторинг в отдельные события, если события становятся слишком разные
• Pro - не нужно будет искать событие таблица на дополнительный параметр все время («тип события»)
• Con - Потенциально много таблиц
• Con - Может быть, не очень сухой, хотя они могли наследовать от генерала Модель событий, которая не связана с таблицей, или я мог бы реализовать "действует как отслеживаемый" камень

Метод 2:

• Pro - только один стол для всего
• Pro - СУХОЙ по умолчанию
• Con - Стол потенциально станет очень широкий с колонками, которые только полезно для небольшого подмножества событий
• Con - Может потребоваться рефакторинг конкретные события в будущем

Я испытываю желание перейти к методу 1, потому что это своего рода минимально жизнеспособный процесс мышления продукта. Просто сделайте то, что мне нужно, я в итоге добавлю 5 моделей, по 1 для каждого типа событий. Если я добавлю 20 моделей, я смогу провести рефакторинг, используя схему наследования одной таблицы. Но, по крайней мере, в этот момент я буду знать, что я делаю рефакторингом, в то время как разработка будущего требует некоторых догадок.

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

Обновление

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

Answer 1

Существует 3-й вариант:

event_header: 
  id
  date
  time
  type
  code
  ... 

event_type_data: 
  PK(id)
  FK(event_id)
  special_field1
  special_field2 

Ваш запрос на загрузку знает, что тип события, скажем, 4, поэтому объединение в таблице event_data

select ev.*, evd.* from event_header ev, event_type_data evd where evd.event_id = ev.id and ev.type = 4 

Избыточное усложнение?Может быть.Помедленнее?Наверное.Смущает будущих разработчиков?Да.Жизнеспособное?Конечно.

Я бы, наверное, пошел со способом 2 и имел бы текстовое поле для специальных данных в формате JSON или XML или просто «ключ: значение, ключ: значение»

Answer 2

Метод 2 - это правильный способ . Я всегда так делал, за исключением того, что я называю это журналом аудита, делаю его очень общим и использую его для многих вещей.

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

Псевдо DDL - типы могут различаться.

CREATE TABLE Audit
   Type           # FK identifying the entry type
   DateTime       # entry time
   RequesterID    # FK identifying the user/process initiating the request
   Object         # Filename etc.
   ObjectClass    # FK defining type of the object 
   AccessType     # FK defining the type of access (download etc.)
   AccessOverride # FK set if accessed via impersonation
   Status         # FK result of operation - success / fail
 ;

ПРИМЕЧАНИЕ. Первоначально это было в основном основано на модели журнала аудита VMS.

Answer 3

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

OneНедавно для меня был решен вопрос о ширине таблицы: хранить множество подробностей о событии в виде большого двоичного объекта XML.В наши дни MSSQL достаточно хорошо его поддерживает, и я в любом случае могу создать любой простой инструмент отчетности.С точки зрения ре-факторинга конкретных событий и т. Д. ... это часто сводится только к инструментам отчетности.Я, конечно, не эксперт по модели данных, и я не могу посоветовать вам очень крупномасштабные таблицы, но в прошлом, работая с людьми из базы данных, они всегда предпочитали метод 2 и имеют представления сборки /отчеты / др.вокруг этого.