在 webapps 中探索用户特定的数据

Question

我正忙于设计一个简单的待办事项列表 web 应用程序，用户可以在该应用程序中进行身份验证并保存待办事项列表项。用户也只能查看/编辑他们添加的待办事项列表项。

这似乎是大多数 Web 应用程序（或一般应用程序）中的通用功能（经过身份验证的用户只能查看自己的数据）。

对我来说，重要的是了解实现这一目标的不同选择。我想要实现的是一种可以有效处理大量用户数据的解决方案。目前我正在使用关系数据库执行此操作，但 noSQL 答案对我也很有用。

我想到了以下想法：

每次需要此“功能”时添加一个 user_id 列。

添加关联数据的关联表（在上面的示例中为 user_todo_list_item 表）。

以这样一种方式设计，即每个“功能”的每个用户都有一个表......所以你会有一个 todolist_userABC 表。这是一个选项，但我不太喜欢它，因为一千个用户意味着一千个表？！

为特定“功能”添加行级安全性。我不熟悉它是如何工作的，但它似乎是一个有效的选择。我也不确定这是否是特定于数据库供应商的。

在我的选择中，我选择了 todolist_item 表中的 user_id 列。虽然它可以完成这项工作，但我觉得如果表中的数据足够大，读取数据时 user_id 列可能会出现问题。我猜可以添加一个索引，但我不确定该索引的有效性。

我不喜欢的是，我需要为我想要这种类型的功能的每个表都有一个 user_id，这对我来说似乎不正确？似乎当我实现数据库层时，我必须将它添加到我的每个功能的查询中（除非我使用一些 AOP）？

我环顾四周 (How does Trello store data in MongoDB? (Collection per board?))，但它没有谈到有关 user_id 列或类似内容的技术。我还尝试在一些安全框架（具体为 Spring Security）中阅读此内容，但它似乎只涉及表级别而不是行级别的特权/权限？

所以问题是我的选择是否合适，是否有更好的技术来做到这一点？

Answer 1

您的选择是自然而然的事情。

每个用户的表是不可启动的（任何修改数据库结构以响应用户操作的行为通常都是可疑的）。

行级别的安全性对于 web 应用来说并不是一个真正的选项——它要求每个用户会话都有一个单独的、持久的数据库连接，这几乎是不切实际的。是的，它是特定于供应商的。

如何索引表完全取决于您的使用模式和要运行的查询类型。 '显示用户的所有 TODO' 是您想要支持的查询（似乎是这样）？然后显然需要对用户 ID 进行索引。

为什么你觉得有一个 user_id 列是错误的？如果要限制用户访问，则需要能够识别记录所属的用户。实际上并不意味着 每个 表都需要它 - 例如，如果一条记录组成另一条记录（例如，您的 TODO 有“步骤”，每个步骤都属于一个 TODO），那么只有对象图需要用户ID。