客户端连数据库，是直连还是用socket?

Question

项目要求客户端不能直连远程的数据库，所以要用socket传输dataset或者webservice的方式。以前写过socket传输，但是没接触过webservice，不知道二者有何优劣。最后还是想问下，大并发和数据量的情况下，是直接连接数据库效率高还是使用网络通信的方式效率高呀？项目对实时性要求较高。数据库webservicedatasetsocket网络

Answer 1

要是对性能要求高，当然是用 socket 了， webservice肯定没有你自己写 socket 来得快，但是这个就比较考验写 socket 的水平了

Answer 2

看具体的需求选择如何优化吧, 不访问数据库, 可以采用 访问缓存的方式. 客户端与服务器采用Socket或者 UDP广播(每个客户端所需要的数据内容相同时, 可采用UDP)

Answer 3

这个东西理解的层次是不同的。最低级地，是不能把关系数据库暴露在公网（或者大企业的单个小网段外），而应该通过自己开发的专用业务应用服务对客户端提供服务。其次低级地，既然需要做c/s程序，干脆就做成在互联上各种“较差、教复杂”的网络环境条件下，也能畅通无阻地运行的网络系统。比如你用到的QQ就可以在全球各种内网内（包括手机内）使用。高级一点的层次，就有丰富的专业性的设计知识了。简单来说，比如说一个网络游戏软件，可以同时让素不相识上千人在同一个虚拟人生世界中相遇、做任务、交互。此时有些人可能就以为，各种操作都是客户端把数据Insert到服务器的SQL Server数据库，然后别的客户端都去 select .... from ..... 来判断自己是否与别人相遇、做任务、交互。这就是纯粹是开玩笑了。但是很多人都是这样以为的，因为他仅仅见过OA程序，没有见过真正的实时业务系统的服务器设计。但是你就可以想象一下，真正的实时业务系统，比如说几千人同时在线的网游，比如说大企业的几百个工作一千人同时在线的工作流系统，比如说各种企业即时通讯工具等等，比如说支持几亿手机IP方式通讯的计算机网络，哪怕就是一个快递公司用来显示和协调各快递员的线路地图系统，等等，有哪些是用简单地“客户端程序调用SQL Server的客户端驱动来对其增删改查”就能做好敏捷的业务服务器的呢？设计一个真正的业务服务器时考虑的是业务服务和业务实体，也就是业务逻辑层，而根本不是什么sql语句“增删改查”。如果是了解这种业务服务器系统设计的人，他又怎么会去纠结“是否调用客户端驱动来对SQL Server增删改查”呢？只有做惯了小办公室内的OA程序的人才习惯于这样考虑c/s系统架构。

Answer 4

随便举出九牛一毛的一点，比如说要实时跟踪各个快递员的位置信息，那么在内存里设置一个 List<Courier> 集合就行了，每一个快递员都有经纬度信息。这类东西绝不用速度慢几百倍的数据库来实现的，数据库只是用来异步地做持久化备份的，而不是唯一地用来支撑实时业务系统的。

Answer 5

关于web service，除非给别人的遗老系统连一下的时候，否则我是不用的。现在各种通讯方式都讲求轻量级，传递json字符串消息就行了，没有必要做高度复杂的封装和解析。

Answer 6

编程的最终目的，当然是越简单越好。能不写代码就不写代码，能不new什么对象就不new对象。能不设计什么class、interface就不要抽象。能不使用高级的c/s概念来架构时，就直接调用关系数据库的客户端驱动好了。但是实践中，需要的时候，这些都会被熟练的设计人员大量使用。而有些人，自己没有把自己放到那种更高要求的公司或者项目中，仅仅因为时髦而纠结于那些“技术”，就很难体会到实践者的乐趣。

Answer 7

建议用中间层，而不是直连。一是安全问题，二是维护方便。可以用webservice，简单，或者wcf