【求大神指点】SQL Server 如果有N多个用户同时访问数据库问题？

[junoveia]

SQL Server 如果有N多个用户同时访问数据库问题.
如果有成千上万个用户同时访问数据库并进行增、删、改、查等操作，如何实现才好呢？
相关例子：医院管理系统
一个医院有n多个病人在挂号并看病，病人的所有相关资料信息都在里面，这是一个医院，要是同是有多家医院都在用这个系统怎么办？
问题一：
数据库设计一个整体的
所有医院都访问这个一数据库，如果数据量庞大，查询是一个大问题，更重要的是当一个医院出现错误，导致整体系统都瘫痪了，所有的医院都用不了这个系统了？
问题二：
如果把每个医院的数据库都分开，每个医院相对独立了，这样数据量相对会少一些，但是也同样存在查询问题，这样一来每个医院的数据库独立了，那么系统又怎么实现统一管理呢？我是新手，希望高人指点一下或给个可行的思路！在此谢过了！！！

[专注or全面]

我个人是感觉分开了好，一套应用程序对应一个数据库，多家是多少家，50家，一百家？怎么不好管理了

[發糞塗牆]

看定位吧，如果你只考虑三甲医院，那数量不多，按医院分库可行，但是如果你要想挂号网那种，那最好设计成一个库

[junoveia]

引用 1 楼 x_wy46 的回复:

我个人是感觉分开了好，一套应用程序对应一个数据库，多家是多少家，50家，一百家？怎么不好管理了

医院我是举的例子，如果数据库分开的话，那要是修改数据库中某一个表的字段，50家至100家都好办，如果要是成千上万呢？那就是一种灾难性的修改了，主要目的是这个系统能够统一管理所有的分支。要怎么解决才好啊？

[junoveia]

引用 2 楼 DBA_Huangzj 的回复:

看定位吧，如果你只考虑三甲医院，那数量不多，按医院分库可行，但是如果你要想挂号网那种，那最好设计成一个库

按分库来做，如何才能实现统一管理呢？有什么方法或有什么思路吗？谢谢！

[俺是大菠萝]

你这个问题确实是新手提出来的； 1、病人有成千上万，但不是这成千上万的病人要同时挂号、看病、取药的。就像你到医院看病，先要排队挂号，执行挂号这个操作的工作人员只有2、3个，所以并发量只有2~3个连接； 2、集中管理要有，分布式存储也要有，这是需要根据你的需求进行平衡的。由于每个医院的业务范围不一定一样（性质上有综合性、专科之分，而且从财务看一般也是独立核算），所以一般还是各自有一套数据库系统；对于管理中心而言，只需要把所需的数据定期同步过来即可，这个是通过数据库级的数据同步机制实现的；

[發糞塗牆]

我目前能想到的可能只有两种方案： 1、从应用程序前端着手，强制或者半强制从用户中获取ta要访问的足够识别哪个医院的信息，比如让ta输入医院名做模糊匹配，然后前端再把请求发送到对应的数据库中。 2、建一个库，存放一些常用搜索条件及对应的医院信息，然后通过跨库访问对应的数据库，但是这个性能较差。 单纯从我想到的两个方案来看，我比较偏向第一种。

[junoveia]

引用 6 楼 DBA_Huangzj 的回复:

我目前能想到的可能只有两种方案： 1、从应用程序前端着手，强制或者半强制从用户中获取ta要访问的足够识别哪个医院的信息，比如让ta输入医院名做模糊匹配，然后前端再把请求发送到对应的数据库中。 2、建一个库，存放一些常用搜索条件及对应的医院信息，然后通过跨库访问对应的数据库，但是这个性能较差。 单纯从我想到的两个方案来看，我比较偏向第一种。

你说的第一种方案我想过，就是建立一个整体的数据库，通过这个医院的编号（维一的）来获取这个医院的信息，但是信息量太大，会很慢，要怎么优化才好？

[發糞塗牆]

引用 7 楼 junoveia 的回复:

[quote=引用 6 楼 DBA_Huangzj 的回复:] 我目前能想到的可能只有两种方案： 1、从应用程序前端着手，强制或者半强制从用户中获取ta要访问的足够识别哪个医院的信息，比如让ta输入医院名做模糊匹配，然后前端再把请求发送到对应的数据库中。 2、建一个库，存放一些常用搜索条件及对应的医院信息，然后通过跨库访问对应的数据库，但是这个性能较差。 单纯从我想到的两个方案来看，我比较偏向第一种。

你说的第一种方案我想过，就是建立一个整体的数据库，通过这个医院的编号（维一的）来获取这个医院的信息，但是信息量太大，会很慢，要怎么优化才好？[/quote]这种方案不应该存储太多信息，主要是能唯一标识医院的信息即可，比如医院名称、地区、级别等等，就类似一个指向牌的功能，真正的医院信息应该是另外的库，你只是把请求分发到对应的库而已。

[發糞塗牆]

所以这个库不会太大，甚至直接在应用服务器上做个小的枚举即可。

[junoveia]

引用 5 楼 u013226693 的回复:

你这个问题确实是新手提出来的； 1、病人有成千上万，但不是这成千上万的病人要同时挂号、看病、取药的。就像你到医院看病，先要排队挂号，执行挂号这个操作的工作人员只有2、3个，所以并发量只有2~3个连接； 2、集中管理要有，分布式存储也要有，这是需要根据你的需求进行平衡的。由于每个医院的业务范围不一定一样（性质上有综合性、专科之分，而且从财务看一般也是独立核算），所以一般还是各自有一套数据库系统；对于管理中心而言，只需要把所需的数据定期同步过来即可，这个是通过数据库级的数据同步机制实现的；

第一条您说的对，可能是我的例子举的不好，拿QQ空间说吧，同时有N多个人在访问QQ空间，并进行增、删、改里面的内容，如何实现这样的数据库管理呢，希望您给一个思路。谢谢大神！ 您说的第二条方案，我觉得比较好，您能详细说一下吗？谢谢，我的QQ：1378962920。

[junoveia]

引用 8 楼 DBA_Huangzj 的回复:

[quote=引用 7 楼 junoveia 的回复:] [quote=引用 6 楼 DBA_Huangzj 的回复:] 我目前能想到的可能只有两种方案： 1、从应用程序前端着手，强制或者半强制从用户中获取ta要访问的足够识别哪个医院的信息，比如让ta输入医院名做模糊匹配，然后前端再把请求发送到对应的数据库中。 2、建一个库，存放一些常用搜索条件及对应的医院信息，然后通过跨库访问对应的数据库，但是这个性能较差。 单纯从我想到的两个方案来看，我比较偏向第一种。

你说的第一种方案我想过，就是建立一个整体的数据库，通过这个医院的编号（维一的）来获取这个医院的信息，但是信息量太大，会很慢，要怎么优化才好？[/quote]这种方案不应该存储太多信息，主要是能唯一标识医院的信息即可，比如医院名称、地区、级别等等，就类似一个指向牌的功能，真正的医院信息应该是另外的库，你只是把请求分发到对应的库而已。[/quote] 可能是我的例子举的不好，拿QQ空间说吧，同时有N多个人在访问QQ空间，并进行增、删、改里面的内容，（用户的操作比QQ空间操作的内容要多很多的情况下）如何实现这样的数据库管理呢，如果说是分库的话，要怎么分才能保证统一管理呢？ 就是用户访问的并发量比较大 并且每个用户下的资料信息都要比QQ空间复杂的多。集中管理，分布式存储这个是怎么实现的能给个思路吗？

[發糞塗牆]

qq的我就不好说什么，但是我觉得腾讯应该有分库、分表机制，至于怎么分表这是个高难度的活，它们也肯定不是随便分的，但是这种情况下使用分布式数据库管理系统能提高不少效率

[junoveia]

引用 12 楼 DBA_Huangzj 的回复:

qq的我就不好说什么，但是我觉得腾讯应该有分库、分表机制，至于怎么分表这是个高难度的活，它们也肯定不是随便分的，但是这种情况下使用分布式数据库管理系统能提高不少效率

百度好像也是用的分布式管理，我对这个是一点经验都没有，你对分布式管理有经验吗？指点我一下，谢过了。

[發糞塗牆]

我也没搞过。这东西目前国内资料较少，只能看看国外有没有类似的

[junoveia]

哪们大神指点一下啊，推荐一些书或视频也行，谢谢。

[俺是大菠萝]

引用 10 楼 junoveia 的回复:

[quote=引用 5 楼 u013226693 的回复:] 你这个问题确实是新手提出来的； 1、病人有成千上万，但不是这成千上万的病人要同时挂号、看病、取药的。就像你到医院看病，先要排队挂号，执行挂号这个操作的工作人员只有2、3个，所以并发量只有2~3个连接； 2、集中管理要有，分布式存储也要有，这是需要根据你的需求进行平衡的。由于每个医院的业务范围不一定一样（性质上有综合性、专科之分，而且从财务看一般也是独立核算），所以一般还是各自有一套数据库系统；对于管理中心而言，只需要把所需的数据定期同步过来即可，这个是通过数据库级的数据同步机制实现的；

第一条您说的对，可能是我的例子举的不好，拿QQ空间说吧，同时有N多个人在访问QQ空间，并进行增、删、改里面的内容，如何实现这样的数据库管理呢，希望您给一个思路。谢谢大神！ 您说的第二条方案，我觉得比较好，您能详细说一下吗？谢谢，我的QQ：1378962920。[/quote] 但从并发这一个指标来说，医院和qq空间就不是一个数量级的。 如果拿QQ空间举例，单有数据库是不够的，前端的Cache是很重要的组件，所有的连接都打到数据库上，肯定受不了；

[junoveia]

这个问题一直没有得么一个好的方法解决。。等待高人出现。。

[tcmakebest]

一个假想的系统想怎么就怎么了, 不过考虑到独立性, 都是分库的, 然后有一个中心库会保存所有数据供查询.

[dali88888]

数据库有一种技术是事物的完整性，有一种技术是锁。