关于数据库设计的问题，大家来讨论讨论！

[wcnm54088k]

现在要做一个系统，系统是要求总公司和N个分公司用同一个系统，但是要把每个公司的业务区分开，即分公司A的员工进去系统，只能查到A公司的业务数据，举个例子吧
比如有个订单表 TE
字段有 TEID TENAME
分公司A有个订单存在里面
TEID TENAME
1 A1
分公司B有个订单存在里面
TEID TENAME
2 B1
现在A公司的员工进去只能看到 1 A1
B公司的员工进去只能看到 2 B2
还有些人有特殊权限的，比如老总要看所有公司的订单，就应该能全部看到
目前我想到的有2个方法
首先说下，这个系统比较大，相应的表也会很多
方法一：在每个表里面都加个字段，表示是哪个公司的业务
方法二：把每个分公司的数据都单独建一个数据库存起来
数据库的操作会写成一个封装类，我说下个人认为这两种方法的优缺点
1、方法一sql语句比方法二繁杂，每句sql后面都要添加 公司id=
2、数据库改动方面，由于客户在系统正式运行后可能要求添加新功能，而新功能在现有的数据库中不能满足客户的需求，需要新加字段或表，这时方法二对于数据库的改动就比方法一更麻烦
3、方法一种每个表中的数据量比方法二更庞大，子公司单查询的时候比方法二更耗时，但是总公司统计的时候，方法二回涉及到跨数据库操作，方法一反而更便于统计
不知道有没有更好的方法，各位讨论讨论！

[chuanzhang5687]

加一个公司id 就繁琐复杂了？

[cd731107]

方法一比较好，结构清晰完整，一目了然，不会产生混淆和岐义，
查询慢的化可以加必要的索引

[chuanzhang5687]

个人认为第一种比较好。
查看权限是在数据库中设置吗？
数据库反正都要改动，就在原来的数据库上面加表加字段吧。

[AcHerat]

长远考虑还是第一种吧！假设是第二种，楼主说了有N个分公司，如果有100个，那么得100个库，要想把这些分公司的数据都做个统计，那么得跨100个库做查询，我想楼主也不大喜欢写这么繁琐的统计SQL，而且还要去优化性能什么的。

1、加个公司id=? 这个不能说是繁琐，有必要了加个非聚集索引，效率影响不大。
2、第一种对以后的二次开发不会造成太大的影响。
3、数据量庞大，这个是不可避免的，楼主可以做的就是加历史表，分区表，对表加必要的索引统计信息，优化统计的SQL语句来提高性能。

[wcnm54088k]

[Quote=引用 6 楼 chuanzhang5687 的回复:]
个人认为第一种比较好。
查看权限是在数据库中设置吗？
数据库反正都要改动，就在原来的数据库上面加表加字段吧。
[/Quote]
查看权限是在数据库中设置的，功能连接都在数据库保存的

[wcnm54088k]

[Quote=引用 7 楼 acherat 的回复:]
长远考虑还是第一种吧！假设是第二种，楼主说了有N个分公司，如果有100个，那么得100个库，要想把这些分公司的数据都做个统计，那么得跨100个库做查询，我想楼主也不大喜欢写这么繁琐的统计SQL，而且还要去优化性能什么的。

1、加个公司id=? 这个不能说是繁琐，有必要了加个非聚集索引，效率影响不大。
2、第一种对以后的二次开发不会造成太大的影响。
3、数据量庞大，这个是不可避免的，楼主可……
[/Quote]
貌似有道理

[wcnm54088k]

[Quote=引用 4 楼 chuanzhang5687 的回复:]
加一个公司id 就繁琐复杂了？
[/Quote]
好像有点繁杂呢，你想想，一个系统多少句SQL啊，每句SQL都成这样子
SELECT * from table where gsid=
看起来怎么感觉都很别扭

[ForLife5518]

同意第一种方案，不敢想像还能想到第二种方案.

[丰太君]

我知道的是广东的整个移动的人员数据几十万条，都没分库。都用同一张表。
涉及较多数据的表，加个字段，时间分区字段。

[BigInt]

需要考虑扩展性，现在N个分公司，生意好就可能变成N+M个分公司，当然不好了也可能变成N-K个分公司

这种情况，第二种设计如何适应？

[chuanzhang5687]

有时候还是要动动手的。[Quote=引用 10 楼 wcnm54088k 的回复:]
引用 4 楼 chuanzhang5687 的回复:
加一个公司id 就繁琐复杂了？

好像有点繁杂呢，你想想，一个系统多少句SQL啊，每句SQL都成这样子
SELECT * from table where gsid=
看起来怎么感觉都很别扭
[/Quote]

[chuanzhang5687]

如果你偏要用第二种内就按照你的意思做吧，重新建库建表。[Quote=引用 13 楼 bigint 的回复:]
需要考虑扩展性，现在N个分公司，生意好就可能变成N+M个分公司，当然不好了也可能变成N-K个分公司

这种情况，第二种设计如何适应？
[/Quote]

[shadowdudu]

我觉得 是增加一个公司ID，然后各个分公司数据自动同步复制到总公司，总公司的负责查询，各个分公司的查询和操作就在自己数据库进行查询

[gw6328]

一公司数据多大？
n个公司数据多大，如果一套库，公司数据大了。后面还是麻烦。

[gw6328]

我倒喜欢一个公司一套。因为老总级别看的是少数
就是把各公司数据汇总。这样可以在各公司汇总的基础上再来操作，不会出来在一个表中对所有公司的数据操作。
而且这样也方便各公司自己和理。
要是一套库，那么出现问题怎么办？n家公司等到恢复了才运行业务,不应该。分开自己管理就不一样了。
那一个公司出现问题不影响基他公司正常运行。

[silentcross]

从性能讲自然是将数据分割，也不一定要另外建立一个数据库，另外建立也个表就可以了，只是这个选择需要很小心，系统里不可能只有订单表吧，还有没有其他表是需要按公司分开的，通常数据库的表就代表一个对象，现在按公司分，把一个对象切分成几个会使系统复杂化，你得考虑系统中的全部表才能做决定。

第一种方法，每个sql加个判断公司的条件也不是那么难以接受吧，或者给每个公司创建一个视图，屏蔽掉这个问题

[wcnm54088k]

[Quote=引用 19 楼 silentcross 的回复:]
从性能讲自然是将数据分割，也不一定要另外建立一个数据库，另外建立也个表就可以了，只是这个选择需要很小心，系统里不可能只有订单表吧，还有没有其他表是需要按公司分开的，通常数据库的表就代表一个对象，现在按公司分，把一个对象切分成几个会使系统复杂化，你得考虑系统中的全部表才能做决定。

第一种方法，每个sql加个判断公司的条件也不是那么难以接受吧，或者给每个公司创建一个视图，屏蔽掉这个问题
[/Quote]
几乎所有表都要按照公司分呢
而且以后对数据库的操作，比如添加字段，新建表，都是写好程序操作，不到数据库去操作

[wcnm54088k]

[Quote=引用 18 楼 jinfengyiye 的回复:]
我倒喜欢一个公司一套。因为老总级别看的是少数
就是把各公司数据汇总。这样可以在各公司汇总的基础上再来操作，不会出来在一个表中对所有公司的数据操作。
而且这样也方便各公司自己和理。
要是一套库，那么出现问题怎么办？n家公司等到恢复了才运行业务,不应该。分开自己管理就不一样了。
那一个公司出现问题不影响基他公司正常运行。
[/Quote]
我得说一下，不管数据库怎么建，程序怎么写，都是放在一个服务器上的，当然，你说的这个问题也是在考虑中

[silentcross]

[Quote=引用 20 楼 wcnm54088k 的回复:]
几乎所有表都要按照公司分呢
而且以后对数据库的操作，比如添加字段，新建表，都是写好程序操作，不到数据库去操作
[/Quote]

完整的系统当然不应该再手动操作数据库，所有表按公司分也不是行不通，只是你得衡量这值得不值得
要是按全部按公司分开那得怎么做，那么每次添加一个公司就得添加一套表，旧的sql就不能用了，
所以你得动态生成sql，所以你得有一套机制来管理这些公司的信息，公司A的订单叫Order_A,公司B的订单叫Order_B，公司A的产品叫Prod_A，公司B的产品叫Prod_B等，首先你要查知这些表名，然后动态构成sql执行查询、更新、插入等。 此外，你还需要至少2套sql，因为总公司是查询所有的表。
你想要的只是各公司的数据视图不一样，这样子做值得不值得

[June_Xiao]

[Quote=引用 18 楼 jinfengyiye 的回复:]
我倒喜欢一个公司一套。因为老总级别看的是少数
就是把各公司数据汇总。这样可以在各公司汇总的基础上再来操作，不会出来在一个表中对所有公司的数据操作。
而且这样也方便各公司自己和理。
要是一套库，那么出现问题怎么办？n家公司等到恢复了才运行业务,不应该。分开自己管理就不一样了。
那一个公司出现问题不影响基他公司正常运行。
[/Quote]
我个人觉得要看分公司规模以及数据量，如果分公司规模比较小，订单数低于十万/年，可以用同一个库，如果数据很大，可以考虑分公司用中低端数据库，订单+公司id上传上总公司数据库