Sam*_*Sam 5 schema database-design
唯一与我正在开发的内容最接近的是 Facebook 的用户活动日志。所以我想如果我能问一下 FB 如何可能在数据库层实现这样的功能，那么它可能会让我对如何解决我自己的类似问题有一些了解。
如何在 MySQL 数据库中设计一个模式来保存特定用户的所有活动。在 FB 的例子中，你有很多用户可以做的活动，比如某事、评论某事、添加朋友、使用应用程序等。所有这些活动都有自己的数据库架构，我敢肯定，所以我假设活动日志架构需要以某种方式引用这些其他数据。
所以我要问的是想法。我能想出的唯一想法是创建一个活动表和多个“连接表”，这些表引用了活动表和活动数据（例如对某事的评论、喜欢某事等）。但是，对于每种新类型的活动和新业务逻辑，此模式都需要一个新表来处理这些新表。也许人们无法解决这个问题，但我对一种模式感兴趣，当新类型的活动添加到系统中时，它几乎不需要对模式和业务逻辑进行更新。
需要明确的是，这个问题听起来并不像是我只是想构建另一个 Facebook 克隆。我只使用 FB 作为对类似于我正在尝试做的事情的参考。更抽象地说明我的问题：我试图将我的数据库中的各种数据聚合到一个可以查询的单一模式中，并且只要有一种新的数据，几乎没有任何模式更改，否则是什么重点是什么？FB 有两个这种聚合的实例，活动日志和通知（我能想到的）。
任何帮助表示赞赏。
关系 DBMS 不太适合此类应用程序。RDBMS 非常适合跟踪和实施两个实体（事物 A和事物 B）之间关系的引用完整性。你想要做的是跟踪事物 A和其他事物之间的关系（或至少是许多其他事物）之间的关系。
您的每个选项都包含某种形式的妥协，包括：
稀疏外键列：创建一个活动表，其中具有指向您要跟踪的各种活动的互斥外键列。这是一种完全 3NF 的做事方式，但它仍然需要为新类型的活动添加新列，并导致列稀疏，人们通常会尽量避免这种情况。
Forrest of Tables：创建单独的活动表，每个表跟踪特定类型的活动。然后，您可以创建一个查询或视图，使用 UNION ALL 将各种类型的活动集中到一个位置以进行查询。对于普通表单来说，这也是非常符合书本规定的，但是您最终会得到一个充满活动表的数据库，并且每当您添加新类型的活动时，您都必须创建一个新表并更改视图。
数据驱动联接：使用单个活动表在一个位置捕获活动类型和活动实例。您需要构建更复杂的逻辑来检索活动详细信息，因为这种方法放弃了正式的外键。没有声明性的引用完整性，而且这种方法很像 EAV，这让很多人感到毛骨悚然。另一方面，您最终会得到一个表，没有稀疏列，并且添加新的活动类型不需要更改架构，只需调整一段代码 - 读取活动类型并知道要做什么的代码do 去检索该活动的详细信息。
你需要看看你的敏感点在哪里。您最终将跟踪多少种类型的活动？多久会添加新类型的活动？当同事看到您实施了具有稀疏列（或更糟）EAV 的解决方案时，您是否准备好忍受同事的蔑视？当您回答这些问题时，您将能够选择对您的应用程序做出最令人满意的妥协的方法。