多账号，多人员系统注意事项

多账号，多人员系统注意事项

Part 1：唯一性

这个的意思很简单，在多账号的模式下，在一个账号下唯一的数据，在整个系统下也应该是唯一的，举个例子：

假设有一个多账号的合同管理系统，合同数据表结构如下：

• sckey 合同编号
• comid 公司id

这个时候，在一家公司内部，各个合同编号是唯一的，那么不同家公司的合同编号能一致吗？不能，甚至可以说绝对不能，否则你在多表联查或者单独查询时，都要加上一个comid的搜索条件。以一个吃过这个亏的人的角度跟你说，会复杂很多。

Part 2：不要用JSON存数据

这个是我们公司遇到的一个坑，原先有一个一对多的关系的表，那个时候我们嫌一对多时更新两张表很麻烦，于是，我们把”多“对应的那张表存成了JSON格式的一个字段，这样只要更新一个字段就可以了，本来一切没问题，CURD操作执行的很完美，直到统计数据的时候，傻眼了，几百，几千条数据，数据库更本不能帮我们统计，只能我们把数据一条条拿出来，用代码去解析它，那酸爽，简直不要太爽了，所以只要你不是眼瞎，就不要存成JSON格式。至于这样的关系表结构有什么好处呢？

• 多角度进行数据分析

• 数据之间不会冗余，这样“编辑”，“删除”操作时，不需要去更新冗余的字段。

举个例子：

合同表：contract，

• contract_key 合同编号
• fee 合同金额

合同中的商品表contract_product：

• product_id 商品id

• contract_id 合同id 这里做一个建议，不要使用contract_key作为外键标志，因为这个值毕竟是人为定义的，不如使用数据库id使用安全

• num 商品数量

• product_fee 商品金额

  这个时候我们可以看到在合同表中冗余了一个字段fee，表征合同总金额，这个时候，假设我更新了合同中的商品的部分，那么合同金额就要重新计算一次，这个时候就多了一次update操作。

  上面解释了为什么最好按照数据库的一对一，一对多进行设计，接下来讲解从多角度进行数据分析，假设我们不想看合同信息，仅仅想看商品出售情况，那么只要一条sql语句就可以进行解析：

  select sum(num) as num,product_id from contract_product group by product_id order by num limit(0,10);

  这样就绕开了合同，直接去计算合同中的商品信息，并且统计销量最好的前10件商品。

  我知道现在这样说你们可能觉得我很傻，这不是基础吗？但是当你们遇到因为设计不规范而导致的错误后，才会从心底里认可，原来按照结构进行设计是对的。

  Part 3：同页面不同人群

  这个也是多人员，或者更贴切的叫法应该是”多工种合作”，一个销售流程：

  • 销售新建销售单
  • 销售申请发货
  • 经理批准
  • 仓库发货
  • 财务收款

  其中从“经理批准”开始，其实操作的都是同一样东西：“发货单”，那么需要针对每个不同的人员写一个界面吗？还是 让所有人都在同一个界面进行操作？

  由于我们公司使用的是React进行开发，所以一个界面的JS代码量是很大的，多一个界面都是麻烦，所以我想出的解决办法就是根据当前的路由判断是处于面向哪个用户的界面，这样我再把相同的数据稍稍做一些处理展现给他们，接着修改按钮的触发事件，这样就可以造成面向每个工种都有一个单独的界面的样子了，而且这样一些全局型的工种，比如“财务”就不需要到销售合同中去点击收款了，而是专门有一个自己的管理界面，而从本质上讲，又没有增加程序员的代码量。

  Part 4：自定义好过“备注”

  这个是我前端时间看过一家公司列给我们的需求文档，其中他们在多个页面提了一个很类似的需求，要求要自定义字段，并不是不好实现，而是针对MySQL这种关系型数据库来说，只能压缩成JSON格式去存，但是正如我上面说的，我不喜欢把数据保存成JSON格式，因为将来要是要处理的话，会很麻烦。

  但是，从另一个侧面来推敲，他们想要这样的功能，也是因为原先的“备注”功能不能满足他们的业务需要，所以他们才想要可以自定义数据内容，举个例子就是：商品原先有价格，规格，金额等字段，每个字段对应数据库表的一个字段，但是客户想要给这个商品加一个“行业规则”字段，想要给那个商品加一个“品牌”字段，而且！！！加完之后，他们肯定还会想要可以进行搜索，简直无语了。所以这样的情况下，该怎么解决我暂时还没有解决的办法，只是在这里提一个现象：

  “备注”功能远远不够

  ​