实现 Slack 风格的工作区/实例架构时的数据库结构

Question

我正在开发一个具有 Slack 风格的工作空间架构的应用程序，用户可以在多个“实例”（工作空间）下访问应用程序的相同功能。

我将继续以 Slack 为例来解释我的问题。

在我的应用程序中执行任何操作时，我需要验证用户是否有权对指定资源执行操作，并且该资源与用户位于同一工作区中。

我创建的第一个表（例如用户）与工作区具有简单的数据库关系。例如，使用 Users 表中的 WorkspaceId 字段。

我的问题是，当我创建更多“更远”的表时，例如 UserSettings，这可能与 Users 表存在一对一的关系，我现在必须加入 Users 记录以获取 UserSettings 所在的工作区记录所属。

所以现在我在想是否值得在所有表上添加一个 workspaceId 值，因为我最终会在我的数据库中执行大量 JOIN 以继续验证用户是否有权访问该资源。

寻找可能对场景有所帮助的建议/架构模式。

Answer 1

我假设您对多个 JOIN 语句的主要担忧是查询性能会受到影响。多个 JOIN 语句并不总是意味着查询会很慢。查询性能取决于许多因素，数据集有多大，索引有多好，什么数据库引擎以及最终的查询计划是什么。如果您决定以这种方式规范化数据库，您只会得到大量的 JOIN 语句。使用完整的第三范式很少是模式的正确选择，因为它可能会产生潜在的性能影响。数据的一些重复通常是可以的，您要权衡的是存储成本与查询性能。要决定如何规范化数据库，您应该提出许多问题，下面是一些浮现在脑海中的问题：

1. 您希望进行什么类型的查询？
2. 每种类型的查询多久进行一次？
3. 数据多久会更改一次，是否可以使用缓存？
4. 不同的存储技术是否更适合用例？
5. 某些数据是否足够小，可以全部放在一张表中？

根据我设计用户管理系统的经验，通常以缓存或类似机制结束，以使用户快速获得具有可接受到期窗口的给定用户权限。这意味着您只在到期窗口查询给定用户的数据库，并且大部分时间都在使用缓存。这就是为什么许多安全系统和用户系统不会立即更新设置的原因。您想要授予用户的权限类型越细化和灵活，查询的成本就越高，因为复杂性。此时，您可以决定对数据进行非规范化或使用指导机制。