代码之家 › 专栏 › 技术社区 › b0x0rz

最佳实践-记录事件(常规)和更改(数据库)

logging events database-design

b0x0rz · 技术社区 · 16 年前

需要帮助 记录站点上的所有活动以及数据库更改 .

要求:

应该在数据库中
应该可以通过发起程序(用户名/会话ID)、事件(活动类型)和事件参数轻松搜索

我可以考虑一个数据库设计,但它要么涉及很多表(每个事件一个表),这样我就可以将事件的每个参数记录在一个单独的字段中,要么涉及一个具有泛型字段的表(7个int数值和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

等。。。

所以 以前有人处理过这个 ?任何 最佳做法 / 可以共享的链接 ?

我已经看到了上面提到的通用解决方案,但不知何故,这与我从数据库设计中学到的相反,但是正如您所看到的,需要可跟踪的事件数量之多(每个用户都可以看到这些信息)让我头疼,但我确实喜欢每一个事件比一般的解决方案更有效。

有什么想法吗?

编辑:还有,在某个地方,有没有这样(可能的)事件的权威列表?

THNX

堆栈溢出表示:您所问的问题似乎是主观的,很可能是封闭的。
我的回答:可能是主观的,但这与我设计数据库/编写代码的问题直接相关,所以我欢迎任何帮助。我也试着把想法缩小到2个,所以希望其中一个能占上风,除非已经有了解决这类问题的既定方案。

1 回复 | 直到 16 年前

DVK 16 年前

就最佳实践而言,记录数据库更改(插入/删除/更新)通常是由主表上的触发器完成的,该触发器将条目写入审核表(每个实表一个审核表,具有相同的columsn+when/what/who列)。
作为通用列表的事件列表不存在。它实际上是应用程序/框架/环境/业务需求的函数。就最佳实践而言,最好确定您的事件类型列表是100%平坦的、两级层次结构(类型/子类型-这通常是最好的方法)还是N级层次结构(实现起来更难/效率更低,但非常灵活,并且为适当的企业活动管理-我参与了所有3个方案的实施,所以我在实践中说。
一个表中不需要7个通用in t字段来存储事件详细信息。而是转到标记值对表:
```
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).
```
事件详细信息可以规范化为事件详细信息int、事件详细信息varchar、事件详细信息float,…如果你愿意但不是真的需要。

事件表中的attrib1 atttribn是应用于所有/大多数事件的通用属性,如userid、hostname、pid等…

event_types是一个描述各种事件类型/子类型的表。

根据您决定项目符号点2的方式,此表可以存储类型的平面列表、类型/子类型映射的列表(如我的示例所示)或父类型/子类型的层次结构(为此,您需要两个表,一个用于类型的父/子映射,另一个用于每个类型的类型属性)。

您可能希望有另一个辅助表event_type_属性将事件类型映射到事件详细信息的有效标记。

例子 :

事件:[username]在搜索[search string]并获得[number of results]@datetime后,单击result[result number][result id]

这将导致类似的数据(不是实际的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)