关于数据库性能的问题！

Question

看你对数据的要求怎样了。如实时性、共享等等

Answer 1

分的越多，速度性能自然就越高，维护自然就越不方便。

Answer 2

关键看业务的可拆分性(也可以说是业务的紧密程度)应该尽量将业务不相关的数据放到不同的数据库(甚至服务器)中,将业务紧密相关的数据放到同一库中.

Answer 3

如果担心单机服务器的性能，可以搭建一个分布式的数据库系统。
在同一台机器上，无论采用哪一种方案，只要数据库结构设计的比较合理，性能相差可能不会太大。

Answer 4

谈不上谁优谁劣，
但是对某种特定问题，会有最适合的解决方案

Answer 5

me too.
一个系统无外乎 流程+查询报表，附带Maitenance部分。
[1] 从业务流程层面讲，我赞同"zjcxc(邹建)"的观点，根据业务复杂度尽量的分拆，减少数据交叉度和用户同时在线数(并发操作,数据锁定延时)
流程数据表上面，尽量采用流程线功能分拆，没有子功能分配一张流程表，并且By Trans进行业务流程标识。
[2] 从查询报表上面来看，也和业务分拆相关，但仅从数据性能上面来说，当然是数据越集中越好。
另外，也建议查询报表数据库和流程数据库分离，单独使用Job按照一定的策略进行数据同步。
[3] 其它层面上面考虑，网络环境，数据量层次，用户业务分支频率和个案几率等等。
说了这么多，主要还是：
    业务分拆为主，兼顾报表查询和其它情况。

Answer 6

不好意思，上面有句话打错了
'没有子功能分配一张流程表'——>'每个子功能分配一张流程表'

Answer 7

性能的高低完全来自实际的测试，不好空口谈。
建议先把用户的使用，业务的操作方面理清楚，再确定库如何建立，有可能你都没有别的选择方案。