拜求方案:一个客户有300多个分布在全国各地的零售店,还要时时上传数据,如何做方案? ( 积分: 100 )

danng · 2007-12-09

to : wobudong 感谢你帮我测出了这个问题，我估计造成这个原因是因为服务器端由于某种原因取不到数据库连接所导致，服务器端应有错误日志的。在这方面我会查明白的。

wobudong · 2007-12-09

是的,没错,我看了日志了,是数据库连接显示断开,但数据库是好的啊,别的连接数据库的都没有问题啊.

wobudong · 2007-12-09

明天开会讨论,最终决定用什么技术方案开发我们的产品.

artlink · 2007-12-09

wobudong:    断线处理数据是必需的.    商品价格调整通常在各零售店营业之前处理或者定时处理,客户端系统运行时候,查询基础数据到本地,本地可以利用小型数据库,如access或内存数据库来处理,通常一个零售店的单品量不会超过1000,如果零售店断线,可以使用本地基础数据来进行业务处理. 当网络可以连接,可以更新基础数据,并提交本地业务数据到总部.    零售店在进行销售处理时,通常没必要通过中间层去查询商品价格,本地查询就可以.这样也缓解了中间层的压力.    销售完成,在线以事务方式提交数据,断线暂存本地,网络连通时候提交.   建议你去找一些delphi三层资料看看.

wobudong · 2007-12-09

to artlink: 非常谢谢,我的设计思路和你说的差不多,价格类的这些基础数据等是登陆的时候进行同步,然后都是从本地查询的. 提交的时候肯定要用事务提交,完整性,统一性一定要做到的,提交不成功,要保存到本地,等网络通畅的时候再发送到服务器. 感谢.

读书人 · 2007-12-09

实时连接，网络外面的困素断了，零售店就会运作不了，用三层架构最为理想，服务器固定一个IP,最好是客户端本地数据缓存，定时扫描服务器上数据改动，用更新时间比较，最下载最新的来更新本地数据。

wobudong · 2007-12-10

服务器端可以把需要更新下载的数据打上时间戳,终端可以比较下载,然后更新本地数据.这些都是对终端的离线应用采取的办法,对于定单,审核,会员管理(会员可以用IC),远程查询统计等希望是时时的,而且要求时时的效率比较高.

creation-zy · 2007-12-10

难得的又长又好的帖子，涨了不少见识——踢上来~  ：）

wobudong · 2007-12-10

经过一上午的讨论和争辩,我们最终确定了开发方案,最后确定采用DbAnyWhere4.33-P2P来开发我们的远程系统: 理由如下:   1:稳定性测试和其他的相比差不多,服务器端不用自己写(对我们来说更容易).   2:服务器端存在防火墙等功能,我感觉相对比较安全.   3:对比速度dbanywhere反映最快.   4:并发测试:我们在40~50人的正常使用下,反映还不错.   5:开发方法和我们擅长的Ado,Bde非常接近,对我们来说上手快.   6:我们需要有售后服务和源代码,这个都可以满足.   7:最后大家多数人同意采用 dbanywhere 选定方案以后,付款购买组件是老板的事情了,我得抓紧做项目了. 在后面的开发过程中,大家可以共同讨论. 在此感谢给我提供帮助的各位兄弟,感谢了. 我的信箱： dajiahao868@yahoo.cn 有什么需要讨论的也可以发邮件给我，谢谢．

aerobull · 2007-12-10

我们现在在用的是公司自己写的组件. http方式的,因为我们的很多客户单位是限制除上网以外的其他东西的.http就是首选了. 编程非常方便,同样使用adoquer之类.只不过原来的open,exec之类改成自己的函数引用, 服务端的程序有一点非常重要,要能顶得住ddos,也就是说在ddos期间,可能会有很多客户端连不上,或完全连接不上,但在ddos结束后,应能马上回复,虽然说这是网管的事,但是我还是要建议一下!昨天特意做了个测试,同样的网络,同样的数据 asta返回要40秒,公司的这个玩意却只要19秒左右,真是搞不明白. 经过一上午的讨论和争辩,我们最终确定了开发方案,最后确定采用DbAnyWhere4.33-P2P来开发我们的远程系统: 理由如下:   1:稳定性测试和其他的相比差不多,服务器端不用自己写(对我们来说更容易).     但是最好也要有服务器端的源代码,因为我想该组件的提供方也不超人

拿不到再说.   2:服务器端存在防火墙等功能,我感觉相对比较安全.    建议对服务器进行ddos之类的攻击.看是否能回复.  4:并发测试:我们在40~50人的正常使用下,反映还不错.    你的并发40-50不是同时在线40-50人吧?建议编写程序用线程方式进行模拟. 祝贺你终于决定了!也为支持国产软件出了一份力!

wobudong · 2007-12-10

服务器是核心,肯定要服务器代码的. 40~50人在线,操作速度也正常使用的数倍,问题应该不大.病毒的问题我还没研究过,回头看看. 好,那也算我支持国产吧.哈哈.

没有结婚的程序员 · 2007-12-10

好几天没来看了 这么多人关注 哈哈 空前盛世啊 好贴！！！！！ 通过这么多高手的见解 小结一下现在的多层开发模式 只说技术 不存在对谁的偏见 1.midas 非常优秀的三层框架 可以自己加入压缩处理;开发比较麻烦,效率一般. 2.webservice 这个是比较火的技术,当然分多种,比如 soap ,通过xml的强大优势来实习数据的交互，delphi .net 都支持，基于wsdl,很灵活,不能说效率不好，因为是http协议本身的问题。 3.网站+客户端 这个也是webservice的一种，不过要看写的人的水平了，如果就是简单的asp 输出数据 然后会传，实在不敢恭维。安全性，效率都不行。 4.asta,remobject,dbanywhere组件可以说都不错。 从服务来说,前两者是国外的,如果发现bug可能不会随时给你升级，当然bug可能很少。一般的应用都可以满足。dbanywhere 在实时方面做的不错,反映速度要快很多,当然普通的应用可能很少用到。楼主这样的情况比较少见。如果不是要求实时的话用不到。 5.用别人的技术在拼装起框架,很不可取。版权问题,稳定性问题,框架设计人员水平问题。不说也罢 在说一下udp协议,udp是不可靠的,这种说法不成立。udp不提供可靠的传输机制。并不是说udp不能实现可靠的传输。这是大多数没有搞过网络方面的程序员的一致思想。滑窗协议同样适用与udp.就那qq传文件就可以证明,udp是可以可靠传输的。

没有结婚的程序员 · 2007-12-10

漏了一个 远程桌面 这个其实没必要说 旁门左道 没资格与三层应用比较

wobudong · 2007-12-10

呵呵，说的不错，支持一个． 后面我可以把我使用dbanywhere的经验给大家分享一下，大家一起讨论．

lsz100 · 2007-12-12

好的，我现在用MIDAS。

abc12345678 · 2007-12-13

超市ERP的运转模式：    要视他们公司的情况，一些大超市的局部方式是这样的。（一个店日处理量过万条的）    1、总店一台服务器，     2、每个分店做一个服务器（高端一点的机子就行），一个客户端。 流程：      更新：每日早上或晚上，各分店的服务器把销售数据汇总及更新，然后只提取有用的数据送加总店的服务器，如（分店销售汇总表，分店新增资料）；      日常：分店里的客户端  只是和分店的服务器连接处理，如需更新资料也可手动。      数据库：总店一个数据库，分店一个数据库，（安装的时候，当然拷贝过去啦，之后更新的回传总店的数据库就行了。）

wobudong · 2007-12-13

你说的也不错,属于超市的类型,我们的项目和超市连锁的区别还是比较大的.

wobudong · 2007-12-13

这几天一直在开发我们的系统呢,没来发言, 这几天使用的感觉还不错,我们的开发环境是直接搭建在internet上的,把服务器放在远程服务器上连接好数据库,然后分工开发的.

差不多算了 · 2007-12-13

顶一个.

lsz100 · 2007-12-14

先用MIDAS开发一般的三层应用。大项目用dbanywhere。

拜求方案:一个客户有300多个分布在全国各地的零售店,还要时时上传数据,如何做方案? ( 积分: 100 )

danng

Unregistered / Unconfirmed

wobudong

Unregistered / Unconfirmed

wobudong

Unregistered / Unconfirmed

artlink

Unregistered / Unconfirmed

wobudong

Unregistered / Unconfirmed

读书人

Unregistered / Unconfirmed

wobudong

Unregistered / Unconfirmed

creation-zy

Unregistered / Unconfirmed

wobudong

Unregistered / Unconfirmed

aerobull

Unregistered / Unconfirmed

wobudong

Unregistered / Unconfirmed

没有结婚的程序员

Unregistered / Unconfirmed

没有结婚的程序员

Unregistered / Unconfirmed

wobudong

Unregistered / Unconfirmed

lsz100

Unregistered / Unconfirmed

abc12345678

Unregistered / Unconfirmed

wobudong

Unregistered / Unconfirmed

wobudong

Unregistered / Unconfirmed

差不多算了

Unregistered / Unconfirmed

lsz100

Unregistered / Unconfirmed

Similar threads