新浪微博的“关注功能”数据库是如何设计的

你好。方法有二个：

我觉得是这样设计的

一个字段记录他所关注的好友信息

应该是json的

然后去数据库查最新的就是更新就是

uchome就是这么干的

-- 用户表(如果这个表数据相当多，可以用分区表)

create table userinfo

( userid number(38,0), -- 可以用序列递增值也成，自己看着办

  username varchar2(60),

  phone varchar2(20),

  address varchar2(20),

  sex char(1),

  cdate date default sysdate

  -- 其他字段，自己添加

)

 

alter table userinfo add constraints pk_userinfo primary key(userid)

 

-- 用户关注信息表(如果这个表数据相当多，可以用分区表)：

create table userattention

( userid number(38,0),           -- 用户ID

  attention_userid number(38,0), -- 被关注的用户ID

  status number(18,0),           -- 关注状态(或者说关注等级，自己定义：0代表什么，1代表什么)

  cdate date default sysdate,    -- 创建时间

  udate date default sysdate     -- 修改时间

  -- 其他字段，自己添加

)

 

-- 为保持数据完整性：不管是“用户ID”还是“被关注的用户ID”其ID必须在userinfo表中存在！

alter table userattention add constraints pk_userattention primary key(userid,attention_userid)

alter table userattention add constraints fk_userattention_userid foreign key (userid) references userinfo(userid)

alter table userattention add constraints fk_userattention_att_userid foreign key (attention_userid) references userinfo(userid)

 

userattention表中一个userid对应该可能有N条记录(而不像你说的：用一条记录，其不同的attention_userid 用逗号隔开，这样设置是不合理的)

 

-- 好比QQ号，我的QQ可以添加N个QQ好友，但我想：腾迅应该不会将我这N个QQ好友用字串连成一条记录（这也太吝啬啦）

网上资料说权限设计 = 功能权限 + 数据权限，我认为还是很有道理的。之前项目中只涉及到功能权限，没有数据权限，原因是最开始设计时，数据已经绑定在特定的用户下了，而且涉及到的表数量很少，不需要单独考虑数据权限的问题。

权限管理，最细致的权限管理有 用户，用户组，角色，权限，功能。根据不同的需求适当选择，如 用户量过大，每个人都授权和麻烦，就引入用户组，对用户组赋予权限。功能上也根据业务不同做适当的扩展。由于如用户权限之前存在多对多关系，需要引入中间表。

本系统设计如下：

数据量很小，功能也不复杂，所以只有用户，角色，权限（功能）及产生的中间表。

表中的数据都是提前填的，用户登陆，查ermroleuser表，获取角色，查ermrolefunction表，获取功能，再查ermfunction表，返回该用户的功能的中文，在页面上展示。

功能权限详细设计请参考，本项目也是受此启发：

http://blog.csdn.net/painsonline/article/details/7183613/

需求：给一个原来没有权限的数据配置系统加上登录，权限功能，不同角色查同一张表返回结果不同。

思路：所谓数据权限，关注点在于实体属性值、条件、允许值，用户登录后，查询该用户的查询条件，根据条件获取数据即可。详细表结构设计可以参考： https://zhuanlan.zhihu.com/p/31339794

具体介绍一下每个字段含义：

（1）主键 id；

（2）acl_id 映射权限点表主键，代表每行记录是针对哪个权限点的；

（3）status 代表当前这条配置是否有效，方便临时激活与禁用；

（4）param 代表需要校验的参数名，允许一个请求有多个参数参与数据校验；如果参数复杂，比如包含对象，定义的参数可能为a.b.c 这种多级的形式，建议不要太复杂

（5）operation 代表数据拦截的规则，使用数字代表是等于、大于、小于、大于等于、小于等于、包含、介于之间等，可以根据自己需要增加或减少支持的拦截规则

（6）value1 和 value2 用来和param、operation组成一个关系表达式，比如：1<=a<2

next_param_op 字段根据需要使用，如果一个权限点支持多条数据规则时，连接两个规则之间的 *** 作，|| 还是 &&

（7）seq 字段用于某个权限点包含多条数据权限规则时的顺序

假设有这么一条数据，那么他的含义是：id为1（acl_id）的权限点，配置了一条有效（status=1）的数据规则，规则是：传入参数id（param）的值要大于（operation）10（value1）

这种设计很细致了，当然我的项目没有那么复杂，所以最终没有采用这个。

http://www.cnblogs.com/jeffwoot/archive/2008/12/23/1359591.html 讲述了数据权限设计的演化过程。

本系统跟权限相关的表结构如下：

1、产品研发期——产品上线前首先产品运营要搞清楚产品的定位以及目标用户。产品定位和目标用户决定了产品要解决什么问题、产品的风格，同时会影响后续产品运营的策略。毕竟，产品往往只是解决一个固定人群的需求，而不是一个普遍存在的需求。弄清楚产品定位和目标用户，运营应该参与到产品设计、开发的过程中，同时提供一些产品测试等支持。在这个阶段，产品和运营应当配合的足够默契，制定好符合产品的上线计划。另外，产品运营要做好必要的准备工作：上架渠道整理和账号注册、微信公众号、微博、预热方案制作和执行、产品上线活动方案。还有就是，如果是安卓渠道，大渠道的首发合作必须是要考虑的，例如：百度手机助手、360手机助手、应用宝等，都有新品首发。你必须先了解各大渠道的首发规则，并沟通预约好排期。新品首发可以带来第一批自然增长的“种子用户”，效果还是不错的。2、产品种子期——产品内测期在这个阶段，产品运营主要目的在于收集用户行为数据和相关的问题反馈，和产品策划一起分析讨论进行产品优化。主要关注数据有：页面路径转化，按钮点击，启动次数，启动时间段，停留时长等。这个阶段数据量不求大，但求真实。而产品用户的主要来源就是产品团队邀请的身边的人以及渠道首发的自然新增用户。这里必须要说明的是：种子期的运营工作不仅仅存在于这个阶段，而是存在于产品每一个版本迭代的过程。3、产品成长期——产品爆发期产品本身性能以及体验没有问题以后，接下来就是产品开始大规模推广的重要时机。推广期主要目的在于扩大影响，吸收用户。这个阶段首先要做的就是铺量，覆盖各大渠道

---