Лучшая практика - события регистрации (общие) и изменения (база данных)

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

Требования:

должен находиться в базе данных
должен быть легко доступен для поиска инициатором (имя пользователя/идентификатор сеанса), событие (тип активности) и параметры события

Я могу думать о дизайне базы данных, но либо он включает в себя множество таблиц (по одному на событие), поэтому я могу регистрировать каждый из параметров события в отдельном поле ИЛИ он включает одну таблицу с общими полями (7 int numeric и 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

и т.д...

так кто-нибудь имел дело с этим до? любые лучшие практики/ ссылки, которые вы можете использовать?

Я видел это с общим решением, упомянутым выше, но почему-то это противоречит тому, что я узнал из дизайна базы данных, но поскольку вы можете видеть огромное количество событий, которые необходимо отслеживать (каждый пользователь сможет см. эту информацию) дает мне головные боли, НО Я ЛЮБЛЮ одно событие для решения таблицы больше, чем общий.

любые мысли?

edit: также есть ли, возможно, авторитетный список таких (вероятных) событий?

Thnx

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

Ответ 1

Ведение журнала изменений базы данных в том, что касается вставки/удаления/обновления, что касается лучших практик, обычно выполняется с помощью триггера в основной таблице, записывающей записи в таблицу аудита (одна таблица аудита на реальную таблицу, с идентичные columsn +, когда /what/who ).
Список событий как общий список не существует. Это действительно функция вашего приложения/инфраструктуры/среды/бизнеса. Что касается лучших практик, рекомендуется решить, является ли список типов событий 100% плоским, двухуровневая иерархия (тип/подтип - это обычно лучший подход) или иерархия уровня N (намного сложнее/меньше) эффективный для реализации, но невероятно гибкий и предлагает очень хорошие возможности для правильного управления корпоративными мероприятиями - я участвовал в реализации всех трех схем, поэтому я говорю из практики BTW).
Вам не нужны 7 общих полей int в 1 таблице для хранения сведений о событии. Вместо этого перейдите в таблицу tag-value-pair:
```
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_FLOAT,... если вы хотите, но не действительно требуется.

attrib1-atttribN в таблице EVENTS - это общие атрибуты, которые применяются ко всем/большинству событий, таких как userid, hostname, pid и т.д.

EVENT_TYPES - это таблица, описывающая различные типы/подтипы событий.

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

Возможно, вы захотите, чтобы еще одна вспомогательная таблица EVENT_TYPE_ATTRIBUTES сопоставляла типы событий с допустимыми тегами для EVENT_DETAILS.

Пример:

событие: [имя пользователя] щелкнул результат [номер результата] [идентификатор результата] после поиска [строки поиска] и получил [число результатов] @datetime

Это приведет к подобным данным (не фактическому синтаксису SQL, sue me:):

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)

Ответ 2

Вы еще не просмотрели MongoDB? Это очень быстро на вставках, поскольку у него нет нескольких функций, которые имеют базы данных отношений, такие как MySQL, и, конечно же, вы можете выполнять поиск по любым полям, которые у вас есть в ваших данных. Фактически большинство компаний начинают использовать его для регистрации и аналитики, прежде чем обращаться с более сложными приложениями с ним.