背景
当前使用的物联卡管理平台由于设计时经验不足，很多功能当前无法通过简单的升级来实现。因此需要重新设计数据库的结构。
目标
以当前需要的功能重新设计数据库结构，并充分考虑 SQL 和 NoSQL 两种方案。
业务功能
- 操作：
- 管理员：
- 新建和管理套餐；
- 导入原始号码和库存；
- 新建和管理下级用户；
- 调整下级用户返利比例；
- 创建订单；
- 普通渠道用户：
- 新建和管理下级用户；
- 调整下级用户返利比例；
- 创建订单；
- 末梢用户
- 终端用户：
- 号码充值；
- 查询：
- 查询下级用户；
- 查询归属订单；
- 查询归属号码；
- 统计：
- 上级用户按照时间/返利支付标识统计下级用户返利；
- 统计当前即将到期的归属卡号；
- 其他：
- 权限管理；
SQL 还是 NoSQL
当前的数据库使用的是 MongoDB，因为我的程序实在是太小了，所以我觉得在此可能都没有必要讨论到底是用哪一种来实现。以后碰到性能瓶颈或者有时间了再仔细讨论。
NoSQL 方案
集合
- 用户；
- 号码；
- 订单；
- 运营商 API 账户；
- 套餐；
- 充值订单；
- 充值返利订单；
- 套餐订购订单；
关系
- 用户之间存在上下级关系，是自关联，一对多；
- 用户（一） -> 订单（多）；
- 订单（多） -> 号码（多）；
- 用户（多） -> 号码（多）；
- 号码（一） -> 充值订单（多）；
- 号码（一） -> 套餐订购订单（多）；
- 用户（一） -> 充值返利订单（多）；
- 用户（）
