0

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

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

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

想到了以下想法：

  • 每次需要此“功能”时添加一个 user_id 列。
  • 添加关联数据的关联表（在上面的示例中为 user_todo_list_item 表）。
  • 以这样一种方式设计，即每个“功能”每个用户都有一个表......所以你会有一个 todolist_userABC 表。这是一个选项，但我不太喜欢它，因为一千个用户意味着一千个表？！
  • 将行级安全性添加到特定的“功能”。我不熟悉它是如何工作的，但它似乎是一个有效的选择。我也不确定这是否是特定于数据库供应商的。

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

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

    我环顾四周（Trello 如何在 MongoDB 中存储数据？（每个板的集合？）），但它没有谈到有关 user_id 列或类似内容的技术。我还尝试在一些安全框架（具体是 Spring Security）中阅读有关此内容的信息，但似乎它只涉及表级别而不是行级别的特权/权限？

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

    • 4

    1 回答 1

    0

    你的选择是很自然的事情。

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

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

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

    Why does having a user_id column seem wrong to you? If you want to restrict access by user, you need to be able to identify which user the record belongs to. Doesn't actually mean that every table needs it - for example, if one record composes another (say, your TODOs have 'steps', each step belongs to a single TODO), only the root of the object graph needs the user id.

    于 2013-01-08T20:00:40.167 回答