现在的解决方式是:
   服务器扫描数据库,查找是否有命令要下载,有则取出数据按照一定要求发给指定客户端。数据库的下发命令是由管理平台控制具体字段。不知道这种方式是不是比较主流的?
服务器频繁读取数据库是否影响性能,另外实时性也不能得到保证,现在是10秒钟扫描一次数据库。
大家不知都是如何做的呢?有什么想法、建议、意见大家来交流一下!

解决方案 »

  1.   

    你的是非主流。
    好的应该是客户端与服务端通过tcp/ip协议建立连接。每一方有消息主动发送,另一方可以即时响应,且不消耗资源。 tcp/ip的连接windows下最好的是完成端口,如果连接很少,可以直接用c#的类库也不错
      

  2.   

    如果是sql server 2005/2008,可以用数据库通知服务,就不用服务器程序定时扫描数据库了。
      

  3.   

    你提的问题完全从数据库出发来考虑c/s系统设计,我觉得我很难从你这个思考方法去设计这类商品化系统。如果你不得不从数据库表之类的东西开始去考虑系统架构设计,那么就直接实现即可。对于真正从对象服务器的角度(而不是数据库服务器的角度)去架构c/s系统来说,“避免额外读取数据库”并不是因为性能原因,而是出发点就不应该假设有或者没有数据库。例如我们考虑IM产品支持几万个客户端即时通讯,那么一个信息从A发送到系统之后就在系统服务中发送到B,在考虑直截了当地实现业务需求的第一个层面时跟数据库没有关系(信息不需要落地)。考虑数据库只是用来做备份,既扩展出备份、续传功能的第二个层面才考虑。
      

  4.   

    sql server 2005/2008支持数据依赖,当指定表内容发生改变时会发出事件
    你可在这个事件里将数据发送给客户端
    流程:管理平台->特定字段->依赖变化->发给客户端
    好处:省下计时器,避免频繁的数据库访问每次看到楼上神人的文字,就不由得心生恐惧,往往简单的事情,让他整一些是似而非的概念就变得复杂了
    呵呵
      

  5.   

    WCF不错.我觉得也应该是从架构来考虑问题.
      

  6.   

    数据库可行
    tcpip似乎效力和效果好一些吧