用于设置项目权限的标准关系数据库习惯用法是什么？
答案应该是一般性的;但是，它们应该能够应用于下面的例子。任何苍蝇：添加列，添加另一个表 - 只要它运作良好。
假设Twitter数据库非常简单：我们有一个User表，其中包含登录名和用户ID;我们有一个Tweet表，其中包含推文ID，推文文字和创建者ID;我们有一个Follower表，其中包含被关注者的ID和关注者。
现在，假设Twitter想要启用高级隐私设置（查看权限），以便用户可以准确选择哪些关注者可以查看推文。设置可以是：
在这种情况下，表示查看权限的最佳方式是什么？按顺序排列的优先级是查找速度（您希望能够快速找出要向用户显示的推文），创建速度（不要我想永远发布一条推文），并且有效利用空间（每次我向我的粉丝列表中的每个人发布推文时，我都不应该为每个人添加一行每个追随者我都有一张桌子。）
答案 0 :(得分：1)
看起来像一个典型的多对多关系 - 我没有看到任何你想要的限制，这将允许空间节省与那些典型的关系数据库习语，即一个有两列的表（都是外国的因为当前的关注者可以并且确实一直在变化，所以在发布的瞬间向所有关注者发布推文（我认为这就是你的意思？）< em> 意味着将多个（非常短的）行添加到该关系表中（保留跟随者集的时间戳历史记录的替代方案，以便您可以在任何给定的推文发布时重建谁是关注者）时间在空间上并没有明显好转。）
另一方面，如果您想在查看时（而不是在发布时）检查关注者，那么您可以制作一个特殊的userid人为地意思是“当前用户的所有关注者”（就像你有一个意思是“Twitter上的所有用户”）;快速查找所需的SQL，在这种情况下，看起来很毛茸茸但可行（UNION或OR带有“我作为作者的跟随者的所有推文，而且[人工用户代表]所有粉丝都可读取推文“）。我没有深入研究那个 SQL的迷宫，直到并且除非你确认它是你想到的这个特殊含义（而不是那个看起来更自然但对我来说不那么简单的那个）允许在关系表上节省任何空间，以便“向所有关注者发布推文”。
编辑：OP已澄清他们是指我在第二段中提到的方法。
然后，假设userid是Users表的主键，Tweets表具有主键tweetid和外键author每个推文的作者的用户ID，Followers表是一个典型的多对多关系表，其中包含两列（Users} follower和followee的外键和Canread表是一个不那么典型的多对多关系表，仍然有两列 - 外键到Users是列reader，外键到{{ 1}}是列Tweets（phew ;-)。两个特殊用户tweet和@everybody的定义具有上述含义（以便向所有人，所有关注者或“仅我自己”发布，所有用户只添加一行@allfollowers - 仅选择性地发布到N个人的特定列表中添加N行）。
因此，我认为用户Canread可以读取的推文ID集合的SQL类似于：
@me