Лучшая практика - регистрирующиеся (общие) события и изменения (база данных)
нуждаюсь в помощи с входом всех операций по изменениям базы данных, а также сайту.
требования:
- должен быть в базе данных
- должно быть легко доступным для поиска инициатором (имя пользователя / идентификатор сессии), событие (тип действия) и параметры события
я могу думать о проектировании баз данных, но любой, оно включает много таблиц (один на событие), таким образом, я могу зарегистрировать каждый из параметров события в отдельном поле ИЛИ он связал одну таблицу с универсальными полями (7 числовых интервалов и 7 типов текстов), и зарегистрируйте все в одной таблице с полем типа события, определяющим, какой параметр был записан, где (и надеющийся, что мне не нужны больше чем 7 полей определенного типа, или 8 или 9 или безотносительно числа, которое я выбираю)...
пример записей (обычные вещи):
[username] login failed @datetime
[username] login successful @datetime
[username] changed password @datetime, estimated security of password [low/ok/high/perfect] @datetime
[username] clicked result [result number] [result id] after searching for [search string] and got [number of results] @datetime
[username] clicked result [result number] [result id] after searching for [search string] and got [number of results] @datetime
[username] changed profile name from [old name] to [new name] @datetime
[username] verified name with [credit card type] credit card @datetime
datbase table [table name] purged of old entries @datetime via automated process
и т.д...
таким образом, кто-либо имел дело с этим прежде? какие-либо лучшие практики / ссылки можно ли совместно использовать?
я видел сделанный с универсальным упомянутым выше решением, но так или иначе который идет вразрез с тем, что я узнал из проектирования баз данных, но поскольку Вы видите чистое количество событий, которые должны отслеживаться (каждый пользователь сможет видеть, эта информация) дает мне головные боли, НО я действительно ЛЮБЛЮ одно событие на решение для таблицы больше, чем универсальный.
какие-либо мысли?
править: также, есть ли, возможно, авторитетный список таких (вероятных) событий где-нибудь?
спасибо
переполнение стека говорит: вопрос, который Вы задаете, кажется субъективным и, вероятно, будет закрыт.
мой ответ: вероятно, субъективно, но это непосредственно связано с моей проблемой, которую я имею с разработкой базы данных / написание моего кода, таким образом, я приветствовал бы любую справку. также я пытался сузить идеи 2 так, надо надеяться, один из них будет преобладать, если уже не будет установленное решение для этих видов вещей.
1 ответ
Ведение журнала изменений базы данных, включая вставку / удаление / обновление, в соответствии с передовой практикой обычно выполняется с помощью триггера записи записей в основной таблице в таблица аудита (одна таблица аудита для каждой реальной таблицы, с идентичными столбцами n + столбцы когда / что / кто).
Список событий в виде общего списка не существует. Это действительно функция вашего приложения / фреймворка / среды / потребностей бизнеса. Что касается лучших практик, рекомендуется решить, является ли ваш список типов событий на 100% плоским, двухуровневой иерархией (тип / подтип - обычно это лучший подход) или иерархией уровня N (намного сложнее / меньше. эффективен в реализации, но невероятно гибок и предлагает очень хорошие возможности для правильного управления корпоративными событиями - я участвовал во внедрении всех трех схем, так что я говорю из практики, BTW).
Вам не нужны 7 общих полей типа int в 1 таблице для хранения деталей события. Вместо этого перейдите к таблице пар значений тега:
EVENT_TYPES: (event_type, event_subtype, description, subtype_attr1, ...) EVENTS: (event_id, event_type, event_subtype, timestamp, attrib1, ...) EVENT_DETAILS: (event_id, tag, int_value, varchar_value, float_value).
EVENT_DETAILS можно нормализовать в EVENT_DETAILS_INT, EVENT_DETAILS_VARCHAR, EVENT_DETAILS, но не обязательно, если вы действительно хотите.
attrib1-atttribN в таблице EVENTS - это общие атрибуты, которые применяются ко всем / большинству событий, таким как идентификатор пользователя, имя хоста, pid и т. Д.
EVENT_TYPES - это таблица, описывающая различные типы / подтипы событий.
В зависимости от того, как вы решили пункт № 2, эта таблица может хранить плоский список типов, список сопоставлений типа / подтипа, как в моем примере, или иерархию родительского типа / дочернего типа (вам понадобятся 2 таблицы для это один для родительского / дочернего сопоставления типов и один для атрибутов типа каждого типа).
Вы можете захотеть иметь другую вспомогательную таблицу EVENT_TYPE_ATTRIBUTES, отображающую типы событий для допустимых тегов для EVENT_DETAILS.
ПРИМЕР :
событие: [имя пользователя] щелкнул по результату [номер результата] [идентификатор результата] после поиска [строка поиска] и получил [количество результатов] @datetime
Это приведет к получению данных аналогично этому (не фактический синтаксис SQL, подайте на меня в суд :):
EVENT_TYPES: (USER_ACTION, USER_CLICK, "User clicked something")
EVENTS: (12345, "USER_ACTION","USER_CLICK", @datetime, "[username]",
"app_name", "pid"...)
EVENT_DETAILS: several rows:
(12345, "result_number", 33, NULL, NULL) // Or go into EVENT_DETAILS_INT without NULLs?
(12345, "result_id", 919292, NULL, NULL)
(12345, "search_string", NULL, "how do I log events in DB", NULL)