我将存储公共和私人消费的应用程序级事件（用户 A 添加的内容，用户 B 更新的内容等）。
下面是表格及其关联的过度简化模型。
users
-------
id (PK)
event_type
-------
id (PK)
description
events
-------
id (PK)
user_id (FK)
event_type_id (FK)
created (timestamp)
事件将以时间线格式（顶部的最新事件）为每个用户报告。
我还想添加自定义 uri 参数和事件上下文（用户 A 更新了“我的 Visa 卡”）。
我是否忽略了此设计中的任何潜在缺陷？
你的基本模型没问题。它为您提供了与特定用户相关联的特定类型事件的标准、规范化交集（多对多）。在不了解您的意图或要求的情况下，很难对模型提出任何批评。
我会提出以下意见：
如果你愿意，你可以events.id在events桌子上使用你的PK 。这可能是我会做的方式。但是，您可以选择考虑进行和event组合的 PK 。如果您没有其他表直接引用该表，这将同样好，可能会稍微好一些。必须根据您计划如何管理此表的空间以及事件累积的速度来考虑潜在优势。使用作为一个聚集索引可以创建一个热点。另一方面，如果您没有正确管理页面填充，使用复合键可能会在插入中造成长时间延迟。events.user_idevent_type_ideventsevents.id
你已经提到模型被简化了，但你没有说是什么方式。我要说的一件事是，所呈现的模型提供的关于事件的信息非常少。您知道谁做了什么（以及什么时候） - 但什么仅限于静态描述字符串。我见过（和构建）的其他事件日志系统包括记录事件对象的特定细节的地方。如果我是你，我会问自己这样的问题：
如果events桌子上有一个文本字段可以填写活动期间发生的事情的具体细节，会有帮助吗？
记录另一个项目的哪个实例受操作影响的列（即：events.object_type和events.object_id）是否有帮助？
是否存在具有多个部分的复杂事件，应将其分组为单个逻辑事件？拥有一个允许将多个events记录绑定在一起的字段会有帮助吗？
如果您能告诉我们更多有关您计划如何使用这些活动的信息，从这些信息是如何提供帮助的角度来看，我或许可以为您提供更具体的建议。