一、C/s方式
1、数据存在本地，如果数据要上传，只在上传时连通，传完就断开。
2、数据存在省的远端服务器，在client端，安装程序后，用专线或者拨号连到远程服务器的数据库。
？这种方式好象不太好，长时间占用线路资源？
二、B/s方式，数据库在省的服务器，大家全部到上面进行增删改
这种大家都在上面输入数据，数据库的连接是否拥挤？？？？要怎么考虑连接的量和资源占用？？？？
16 个解决方案
#1
1、数据存在本地，如果数据要上传，只在上传时连通，传完就断开。
#2
还有没有更详细的回答？？？
#3
纪录级别上报
#4
B/s方式的报表报送，实现上有什么好建议，用php开发，有没有组件可利用
#5
????
#6
采用B/S模式
#7
b/s、分布式存储
#8
C/s方式，可以发邮件，
把数据放到一个文本文件里，传过去之后再读回到datawindow里
B/S上报表有点麻烦，表现形式不够，PBWF有这个能力，但现在还不是很好
把数据放到一个文本文件里，传过去之后再读回到datawindow里
B/S上报表有点麻烦，表现形式不够，PBWF有这个能力，但现在还不是很好
#9
用分布式
#10
你好！
我和你遇到了同样的问题，现在也不知怎么解决，也发了贴子，等待高手的帮助，如果解决了别忘了兄弟，我的E-mail：lnwwh@elong.com
我和你遇到了同样的问题，现在也不知怎么解决，也发了贴子，等待高手的帮助，如果解决了别忘了兄弟，我的E-mail：lnwwh@elong.com
#11
如果采用C/S，只能定期上传数据，在服务器端有程序更新。
如果采用B/S，要考虑同时浏览的人数可能的峰值，服务器没有想像的那样不堪重负，如果人数比较多，建议采用Unix/Linux平台，如果人数特别多，可以用小型机，这点不会成问题的，这么多大型网站日访问量很高，也没见什么问题。
如你所说情况，建议采用B/S。如果人数较少或者客户端网络情况不好，则采用C/S。
如果采用B/S，要考虑同时浏览的人数可能的峰值，服务器没有想像的那样不堪重负，如果人数比较多，建议采用Unix/Linux平台，如果人数特别多，可以用小型机，这点不会成问题的，这么多大型网站日访问量很高，也没见什么问题。
如你所说情况，建议采用B/S。如果人数较少或者客户端网络情况不好，则采用C/S。
#12
skysaint(蓉蓉是小破狗) 说得不错，我开发过一个程序，服务端用PB+SQL数据库，客户端用DOTNET+ACCESS数据库，然后拨号将增量数据传到服务端。用得不错。
#13
B/s方式和C/s远程连接数据库的方式比较，网络的占用如何？
B/s下对数据库的连接怎么考虑：
1、登陆后一直保持连接
在查询、提交频繁时，避免导致频繁断开和连接数据库，但是否会到一定数量后，占用数据库的连接资源，性能下降》？
2、需要时连接
保证同时连接数据库的人数,但是频繁断开和连接，效率是否会低？
B/s下对数据库的连接怎么考虑：
1、登陆后一直保持连接
在查询、提交频繁时，避免导致频繁断开和连接数据库，但是否会到一定数量后，占用数据库的连接资源，性能下降》？
2、需要时连接
保证同时连接数据库的人数,但是频繁断开和连接，效率是否会低？
#14
如果B/S，不必考虑这个问题，因为Web服务器和客户端的Session有足够的考虑了。
如果是C/S，确实存在你说的这个问题。但也不是大问题。你可以设置一个时限，通过system idle里设定超时时间。在一个完整的业务模块开始和结束时连接和断开数据库。这是一种折中方式。
如果是C/S，确实存在你说的这个问题。但也不是大问题。你可以设置一个时限，通过system idle里设定超时时间。在一个完整的业务模块开始和结束时连接和断开数据库。这是一种折中方式。
#15
谢谢大家，谢谢skysaint(蓉蓉是小破狗) ，你的意思是说在B/S方式不用考虑多用户同时使用，在软件开发上保证性能的问题，而只需要提高服务器硬件配置就可以。
#16
可以这样理解，当然编码时要注意用好算法了。基本上是这样的。
#1
1、数据存在本地，如果数据要上传，只在上传时连通，传完就断开。
#2
还有没有更详细的回答？？？
#3
纪录级别上报
#4
B/s方式的报表报送，实现上有什么好建议，用php开发，有没有组件可利用
#5
????
#6
采用B/S模式
#7
b/s、分布式存储
#8
C/s方式，可以发邮件，
把数据放到一个文本文件里，传过去之后再读回到datawindow里
B/S上报表有点麻烦，表现形式不够，PBWF有这个能力，但现在还不是很好
把数据放到一个文本文件里，传过去之后再读回到datawindow里
B/S上报表有点麻烦，表现形式不够，PBWF有这个能力，但现在还不是很好
#9
用分布式
#10
你好！
我和你遇到了同样的问题，现在也不知怎么解决，也发了贴子，等待高手的帮助，如果解决了别忘了兄弟，我的E-mail：lnwwh@elong.com
我和你遇到了同样的问题，现在也不知怎么解决，也发了贴子，等待高手的帮助，如果解决了别忘了兄弟，我的E-mail：lnwwh@elong.com
#11
如果采用C/S，只能定期上传数据，在服务器端有程序更新。
如果采用B/S，要考虑同时浏览的人数可能的峰值，服务器没有想像的那样不堪重负，如果人数比较多，建议采用Unix/Linux平台，如果人数特别多，可以用小型机，这点不会成问题的，这么多大型网站日访问量很高，也没见什么问题。
如你所说情况，建议采用B/S。如果人数较少或者客户端网络情况不好，则采用C/S。
如果采用B/S，要考虑同时浏览的人数可能的峰值，服务器没有想像的那样不堪重负，如果人数比较多，建议采用Unix/Linux平台，如果人数特别多，可以用小型机，这点不会成问题的，这么多大型网站日访问量很高，也没见什么问题。
如你所说情况，建议采用B/S。如果人数较少或者客户端网络情况不好，则采用C/S。
#12
skysaint(蓉蓉是小破狗) 说得不错，我开发过一个程序，服务端用PB+SQL数据库，客户端用DOTNET+ACCESS数据库，然后拨号将增量数据传到服务端。用得不错。
#13
B/s方式和C/s远程连接数据库的方式比较，网络的占用如何？
B/s下对数据库的连接怎么考虑：
1、登陆后一直保持连接
在查询、提交频繁时，避免导致频繁断开和连接数据库，但是否会到一定数量后，占用数据库的连接资源，性能下降》？
2、需要时连接
保证同时连接数据库的人数,但是频繁断开和连接，效率是否会低？
B/s下对数据库的连接怎么考虑：
1、登陆后一直保持连接
在查询、提交频繁时，避免导致频繁断开和连接数据库，但是否会到一定数量后，占用数据库的连接资源，性能下降》？
2、需要时连接
保证同时连接数据库的人数,但是频繁断开和连接，效率是否会低？
#14
如果B/S，不必考虑这个问题，因为Web服务器和客户端的Session有足够的考虑了。
如果是C/S，确实存在你说的这个问题。但也不是大问题。你可以设置一个时限，通过system idle里设定超时时间。在一个完整的业务模块开始和结束时连接和断开数据库。这是一种折中方式。
如果是C/S，确实存在你说的这个问题。但也不是大问题。你可以设置一个时限，通过system idle里设定超时时间。在一个完整的业务模块开始和结束时连接和断开数据库。这是一种折中方式。
#15
谢谢大家，谢谢skysaint(蓉蓉是小破狗) ，你的意思是说在B/S方式不用考虑多用户同时使用，在软件开发上保证性能的问题，而只需要提高服务器硬件配置就可以。
#16
可以这样理解，当然编码时要注意用好算法了。基本上是这样的。