关于数据库设计的一些思考

	1（被动）：1（主动）关系		1：n关系		n（被动）：n（主动）关系
示例	会员卡号：客户		客户级别：客户		功能：角色
分析	存在主被动关系，比如一般是为客户设置会员卡号，而不是把会员卡号分配给客户，虽然都可以，但是第一种更符合用户习惯				存在主被动关系，比如一般是为角色设置功能，而不是把功能分配给角色，虽然都可以，但是第一种更符合用户习惯
表设计	在被动方增加是否使用字段，在主动方增加被动方字段，减少关联		在n方中增加1方的id、索引		增加关联表，在关联表中增加两方的id、索引
	1方（被动）	1方（主动）	1方	n方	n方（被动）	n方（主动）
增	自身	自身 + 被动方字段 需要先判断被动方是否存在和是否可用，然后修改被动方使用状态	自身	自身 + 1方id 需要先判断1方是否存在和是否可用	自身	自身
删	需要先判断是否使用	修改被动方使用状态	需要先在n方中判断是否使用	自身	需要先在关联表中判断是否使用	需要在关联表中删除数据
改	自身	自身，被动方字段不能修改	自身	自身，1方id是否能修改取决于是否影响其他关联	自身	自身
查	自身	自身 + 被动方字段	自身	自身 + 1方	自身	自身
再分析					在主动方增加查询和修改关联表接口，如： /roles/{id}/functions GET 表示查询id为xx的角色对应的功能 /roles/{id}/functions UPDATE 表示修改id为xx的角色对应的功能 查询很简单，不再赘述，至于修改怎么做？一个简单的方式是先删除后新增，适用场景： 为角色设置功能 为商品设置标签
特例					客户和优惠券也是n:n的关系，但是无法区分主被动关系，可以将某种优惠券发放给客户，也可以为某个客户发放优惠券，两种场景都合理，并且关联表中还存在另外的字段，如数量、过期时间等。这种情况在两方中都增加查询和修改关联表接口。