探索user应用程序中特定用户的数据

Question

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

在大多数web应用程序(或一般应用程序)中，这似乎是一个通用特性(通过身份验证的用户只查看自己的数据)。

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

想到了以下几点：

​

• 每次需要这个“特性”时都添加一个user_id列。
• 添加关联表(在上面的示例中是user_todo_list_item表)来关联数据。
• 设计的方式，使您有每个用户的每个“功能”表.因此，您将有一个todolist_userABC表。这是一个选项，但我不太喜欢它，因为一千用户的意思是一千张表？！
• 向特定的“功能”添加行级安全性。我不熟悉这是如何运作的，但这似乎是一个有效的选择。我也不确定这是否是特定于数据库供应商的。 在我的选择中，我选择了todolist_item表中的todolist_item列。虽然它可以完成这项工作，但我认为，如果表中的数据足够大，user_id列在读取数据时可能会出现问题。我想可以增加一个指数，但我不确定该指数是否有效。 我不喜欢它的地方是，我需要一个user_id为每一个表，我希望这种类型的特性，这似乎不正确的我？另外，当我实现数据库层时，我必须将它添加到我对每个特性的查询中(除非我使用了一些AOP)。 我看了一下(How does Trello store data in MongoDB? (Collection per board?))，但是它没有提到有关user_id列的技术或类似的东西。我还试着在一些安全框架( security是具体的)中读到这一点，但似乎它只进入了表级别的特权/权限，而不是行级别？ 因此，问题是我的选择是否合适，以及是否有更好的技术来做到这一点？

Answer 1

你的选择是理所当然的事。

每个用户的表是不启动的(任何响应用户操作而修改数据库结构的操作通常都是可疑的)。

行级安全实际上并不是webapp的一种选择--它要求每个用户会话都有一个单独的、持久的数据库连接，这是很难实现的。是的，这是针对供应商的。

如何索引表完全取决于要运行的使用模式和查询类型。“为用户显示所有的待办事项”是您想要支持的查询(看起来应该是这样)吗？然后，显然需要对用户id进行索引。

为什么user_id列对您来说是错误的呢？如果要限制用户的访问，则需要能够识别该记录属于哪个用户。实际上并不意味着每个表都需要它--例如，如果一条记录包含另一条记录(例如，您的TODOs有“steps”，每个步骤属于一个TODO)，那么只有对象图的根需要用户id。