刘睿  10:24:16
如果一个信息是多用户（多公司）的这种，数据库该杂个设计呢
青润  10:32:53
多公司？什么多公司，你的业务原型是什么样子的。
刘睿  10:33:36
就是一个信息系统，是要有几个公司用的，互相不干扰
刘睿  10:34:00
本来我是想一个公司一个数据库，但我又觉得好像没得好大必要一样的
刘睿  10:34:34
就像kingde的K3系统一样，他们就是一个帐套就是一个数据库
青润  10:34:49
没关系呀，权限设置好了就无所谓。
青润  10:34:59
和一个公司的系统同样设计就行了。
刘睿  10:35:35
那很多表上就要加一个公司这个字段了呀
青润  10:38:44
表和什么关联？
公司里面有人，表里面如果有人这个关系，那也是一样表述，就不需要增加公司字段了。
刘睿  10:40:25
比如我一个订单，我如果要查一个公司下的所有订单，那不是比较麻烦了，还要先匹配一个公司下所有人员还把这些人员的所有订单查出来
青润  10:40:39
建立视图，进行搜索。
刘睿  10:41:06
mysql 支持视图吗？
青润  10:41:09
数据库视图就可以做到。
青润  10:41:18
这个我不太清楚，你可以去查一下。一般都支持。
青润  10:42:07
另外，一个公司的人进行操作，操作的时候，他的session或者标示中就应该带有公司属性，一个人不可能让他去查询另一个公司的订单情况。
刘睿  10:44:00
这个我知道，但是大量的查询是基于公司的，比如查整个一个公司的订单，
青润  10:45:49
这个应该是业务逻辑中做好的设计。
一个普通员工查询，只能查询属于他本人的订单情况。
一个公司总经理或者市场总监之类的人才能查询整个公司的订单情况，
而且，这两个应该是在他进入订单界面就直接查询出来的东西，而不是事后搜索关键词匹配的，可以考虑对人员进行分类，只有几个职位的属性必须佩带公司信息，其他的就可以不带。业务实现中也比较容易。
刘睿  10:46:54
每个人都要带上公司属性哒，因为不能查到其它公司的信息了
刘睿  10:47:08
包括整个工作平台
青润  10:47:34
我认为没必要，因为一个人的查询，根据他的个人id编号进行就足够了，不可能id编号出现雷同现象。
刘睿  10:47:37
你的意思只用在人员表上加一个公司字段就行了？
青润  10:47:49
人员表里面本来就必须有公司字段的。
青润  10:48:12
前面那个问题，你考虑得过于复杂了，实际上只要有人员id，就不可能出现两个公司的东西被一个人查询出来的现象。
刘睿  10:50:04
你的意思说多用户设计不用单独考虑？
青润  10:52:26
除了少数公司负责人岗位的考虑外，其他的都不需要考虑。
青润  10:53:18
也就是说，这个数据表的修改和业务模块的改动量并不大，前提是考虑清楚业务关系的实现，同时你的业务系统本身已经设计完美了——如果需要改动，往往是最后这个做得不好
刘睿  10:54:15
我是在做一个进销存软件，是一个集团公司下多个公司用的，不过是订单，还有库存，销售，所以我一开始是考虑是多个数据库
青润  10:54:33
呵呵，没那么复杂。
刘睿  10:54:55
那库存也总要单独带公司属性吧
刘睿  10:55:39
你的意思是直接在原来的系统上，现在我要变成多公司用的，只用在几张表上加上公司字段就OK了
青润  10:56:43
是的。
刘睿  10:57:05
3Q
青润  10:58:27
不客气，呵呵。