答案 0 :(得分：4)
我强烈推荐这种方法。由于您可能使用相同的OLTP和OLAP数据库，因此可以通过添加一些星星和雪花来获得显着的性能优势。
我有一个社交网络应用程序，目前有65个桌子。我维护一个表来跟踪对象（博客/帖子，论坛/帖子，图库/相册/图像等）视图，另一个用于对象推荐，第三个表用于汇总其他十几个表中的插入/更新活动。
我做的一件事略有不同的是维护一个entity_type表，并在object_type列中使用它的ID（在你的情况下，就是'TABLE'列）。您可能希望使用event_type表执行相同的操作。
澄清Alix - 是的，您维护一个对象的引用表，以及一个事件的引用表（这些将是您的维度表）。您的事实表将包含以下字段：
id
object_id
event_id
event_time
ip_address
答案 1 :(得分：3)
它看起来是一个非常合理的设计，所以我只是想挑战你的一些假设，以确保你有具体的理由来做你正在做的事情。
在我完全规范化的数据库中 额外增加约8到10个 表
这些都是从现有数据中得出的统计数据，不是吗？ （更新：好吧，他们不是，所以无视以下。）为什么这些只是视图，甚至是物化视图？
然而，收集这些统计数据似乎是一个缓慢的操作：
我想出了一个表格架构 将分离高度易变的数据 从其他表受到沉重的 读取
我猜你在谈论用户（只是选择一个表）的事件，这些事件很不稳定，与用户数据分开。我同意它应该是分开的，但更多的是因为它是根本不同的数据。有人是谁，有人做了两件事。
我不认为波动性如此重要。 DBMS应该已经允许您将日志文件和数据库文件放在不同的设备上，这样就完成了同样的事情，并且争用不应该是行级锁定的问题。
非关系（仍然没有那么糟糕 EAV）
我认为你错过了树林，可以这么说。
您的表的谓词将是“在DATE EVENTed to TABLE时IP IP的用户ID”，这似乎是合理的，但是存在问题。 （更新：好的，所以它有点像那样。）
您仍然可以将用户事件加入用户，但无法实现外键约束。这是为什么 EAV通常是有问题的;某些东西是否恰好是EAV并不重要。在您的架构中实现约束通常是一行或两行代码，但在您的应用中，它可能是几十行代码，如果多个应用在多个位置访问相同的数据，它可以轻松地成倍增加到数千个代码行。因此，通常情况下，如果您可以使用外键约束来防止错误数据，那么您可以保证没有应用程序会这样做。
您可能认为事件并不那么重要，但作为一个例子，广告展示次数就是金钱。我绝对希望尽可能早地在设计过程中发现与广告展示相关的任何错误。
进一步评论
我可以发现一些警告，但只要 应用程序搞乱了数据库 我知道它在做什么 不应该有任何问题。
有一些警告你可以成为一个非常成功的系统。使用适当的约束系统，您可以说，“如果任何混淆数据库的应用程序不知道它在做什么，DBMS将标记错误。”这可能需要比你更多的时间和金钱，所以你可以拥有的更简单的东西可能比你不能的更完美的东西更好。 C'est la vie。
答案 2 :(得分：0)
我无法在Ben的回答中添加评论，所以有两件事......
首先，在独立的OLAP / DSS数据库中使用视图是一回事;在事务数据库中使用它们是另一回事。性能重要的高性能MySQL人recommend against using views
WRT数据的完整性，我同意，这是使用带有'events'作为中心事实表的星形或雪花的另一个优点（以及像我一样使用多个事件表）。但是你无法围绕IP地址设计参照完整性方案