我公司想开发一个基于B/S结构的进销存，各位请进！

Question

1、B/S结构（放到互联网上）与C/S结构（放到互联网上）在速度上有无差异？
2、由于针对的客户有七家分公司和海外公司，用SQL Server2000数据库最大能承受多少记录？
3、前台开发用什么比较好些？希望大家参与，共讨论，谢谢！

Answer 1

Delphi7--IntraWeb
真的不错啊（不过要懂一点界面设计）

Answer 2

1、处理得好，速度差异应该不大
2、SQL　SERVER应该够用
3、不知是不是JAVA，因为我没做过B/S，乱说一通

Answer 3

to Devchenxip(天天快乐):谢谢，Delphi7+IntraWeb真的可以么？D7在网上有下载的么？to  mrtxc(阿春):谢谢，不是用JAVA，最好能用Delphi实现。

Answer 4

blucecat(灵魂正被delphi吞噬):delphi有.net么？

Answer 5

Delphi7--IntraWeb
真的不错啊（不过要懂一点界面设计）-----------------------------------------------------我感觉不好，IntraWeb开发出来的东西还是一个exe形式的应用程序，只不过
它有个端口，可以以网页的形式显示而已！我感觉这个根本称不上什么B/S!
还是做成Web服务的形式比较好，建议用C#开发！

Answer 6

yutaocool(酷鱼_WQ):谢谢你的建议，用C#能真正体现Web服务形式么，做成之后是不是HTML形式的页面，我没学过C#啊

Answer 7

to  Drate(小虫) :谢谢你！
是呀，有这个想法。
我们之所以想把它放到互联网上就是想让各个公司实现库存共享，因为客户在海外有公司，如果采用远程访问互导库存的话（只能通过拨号网络）不知道能否拨到海外？如果能拨其速度又如何？
一共加起来有十来家公司，针对轴承行业，每天处理数据量一般。
我就是不知道用SQL Server行不行啊，SQL Server能支持多少数据量？还是用大型的例如ORACLE
请指点！

Answer 8

MSSQL大概只能支持T级的数据量,如果贵公司的业务量很大的话,建议采用Oracle 或是DB2
因为你需要B/S结构的,建议用JAVA+Oracle,缺点是开发周期要长些.虽然Delphi也可以做并且
开发周期短,但是维护相对困难.

Answer 9

Drate(小虫) 说的对，一定要考虑数据量的大小和网络的情况。最好先做个调研，再确定用什么数据库。我没做过大型数据库，对ORACLE不太了解，但认为如果数据量不是海量，SQL Server也可以应付。

Answer 10

haike_911(红客):开发的是针对轴承行业的MIS系统。
Guade() ：业务量不是很大，用JAVA，我才刚刚学了一点点。
shanjicn(有容乃大)：如果SQL Server可以的话就不用ORACLE，因为我也没做过啊

Answer 11

lihongyue(虚怀若谷)
是的，是xml或者是asp的页面，还是很不错的，我在网上也见过用C#编的程序
不过网址我忘记了，不好意思！

Answer 12

用ActiveForm开发，发布到网页很容易

Answer 13

不要用ActiveForm恐怕不大好。。建议jsp或者asp吧.Net,c#也行

Answer 14

yutaocool(酷鱼_WQ):没关系，只是我从来没接触过C#啊。
 leilu() ：算是吧。
 HZ_ZMD(爱到哪里都会犯错)：real?
 lotust(何化楠):用ASP开发的话，Delphi里的很多控件ASP都没有啊，怎么办啊

Answer 15

to l_xiaofeng(流水不腐):那您有什么高建么？

Answer 16

用ActiveForm虽然可以实现,但是性能上并不会很好的.
同意cutedelphigirl(delphi女孩) 的提议.

Answer 17

>MSSQL大概只能支持T级的数据量,如果贵公司的业务量很大的话,建议采用Oracle 或是DB2
因为你需要B/S结构的,建议用JAVA+Oracle,缺点是开发周期要长些.虽然Delphi也可以做并且
开发周期短,但是维护相对困难.那倒未必，SQLServer 没你想得那么差。上限来说的确不如 DB2/Oracle，但“大”企业来说也够用了——很多“大”项目中的DB2/Oracle完全没必要（电信/电力/金融等行业外）。典型的例子是： http://www.joyo.com

Answer 18

piggybank(吞硬币的小猪)：谢谢！

Answer 19

asp.net+vb.net+XML+sqlsever
也一样

Answer 20

我们公司就是做进销存的，是C/S结构，
如果要用B/S我想客户肯定会受不了。
除非他的业务量很小

Answer 21

做B/S说实在，　delphi很欠．．．
给你几个方案：
  
    asp + com
    jsp + ejb
    .net

Answer 22

hydonlee(青山情) :谢谢，ASP没有DELPHI的那些控件怎办啊

Answer 23

我倒是想用.net来开发，但是对.net不熟，所以还不行。

Answer 24

既然大家都在谈这个问题，我也来谈谈我自己的亲身体会吧：  举个例子：我们公司是一个服装企业，我们的测试数据中
  货号表记录：84864
  库存表：286560
  库存日记帐表：752056
  
  我就不再说如：入库、出库、盘点、退货、调拨什么的单据了  当然，这只只是进销存的一块。我们公司的网络是100M的光纤，服务器就差没有买小型机了
  
  我们用的是ORACLE的数据库
  最近正好我在做一个用ACCESS数据库的客户端程序，目的就是为了加快客户端数据处理的速度，我们公司已经有了WEB端的物流管理系统，可是，数据处理的效率实在太低，达不到实用的要求，我们只好想办法在负担重的客户端用ACCESS数据库进行本地操作，对于需要交互的数据进行定时更新处理。
  如果真的需要用WEB端，我个人以为，只有在进行数据传输量不大的时候才比较实用，而进销存系统不只只是数据计算量大，而且数据传输的量也是非常大的，举个例子：  输入一张盘点单，我需要查询所有以BB%开头的，属于成品仓库的、在2003-09-04之前 ，属于A客户的仓库库存数量及金额，假设返回结果为200条，就这个查询，你想想在10万级的数据查询中得多长时间？查完了以后，你得有多大的数据量回传到客户端呢？我想最少要3分钟的时间吧。
  
 我想，如果想要做一个项目 ，你首先得弄清楚你的软件以后的运行环境
 有硬件环境及软件环境
 需求分析中：  对性能的规定
3.2.1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.2.2时间特性要求
a． 响应时间<=15秒；
b． 更新处理时间<=5秒；
c． 数据的转换和传送时间<=5秒；
d． 数据等待的要求：出现相应的提示，如鼠标改变为漏斗形状，屏幕出现“正在处理…”的信息等。
3.2.3灵活性
当需求发生某些变化时，该软件系统对这些变化是否需要做出相适应的变化：
a． 操作方式上的变化：否；
b． 运行环境的变化：否；
c． 同其他软件的接口的变化：否；
d． 精度和有效时限的变化：否；
e． 计划的变化或改进：项目的开发时间延长、投入更大。
3.3输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
 
上面的条件决不只是看看而已，而是需要实实在在的去调查，去分析才能得出结果的
如果只是一头扎进去的话，我想到了出问题的时候才发会发现问题的严重性的!

Answer 25

既然大家都在谈这个问题，我也来谈谈我自己的亲身体会吧：  举个例子：我们公司是一个服装企业，我们的测试数据中
  货号表记录：84864
  库存表：286560
  库存日记帐表：752056
  
  我就不再说如：入库、出库、盘点、退货、调拨什么的单据了  当然，这只只是进销存的一块。我们公司的网络是100M的光纤，服务器就差没有买小型机了
  
  我们用的是ORACLE的数据库
  最近正好我在做一个用ACCESS数据库的客户端程序，目的就是为了加快客户端数据处理的速度，我们公司已经有了WEB端的物流管理系统，可是，数据处理的效率实在太低，达不到实用的要求，我们只好想办法在负担重的客户端用ACCESS数据库进行本地操作，对于需要交互的数据进行定时更新处理。
  如果真的需要用WEB端，我个人以为，只有在进行数据传输量不大的时候才比较实用，而进销存系统不只只是数据计算量大，而且数据传输的量也是非常大的，举个例子：  输入一张盘点单，我需要查询所有以BB%开头的，属于成品仓库的、在2003-09-04之前 ，属于A客户的仓库库存数量及金额，假设返回结果为200条，就这个查询，你想想在10万级的数据查询中得多长时间？查完了以后，你得有多大的数据量回传到客户端呢？我想最少要3分钟的时间吧。
  
 我想，如果想要做一个项目 ，你首先得弄清楚你的软件以后的运行环境
 有硬件环境及软件环境
 需求分析中：  对性能的规定
3.2.1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.2.2时间特性要求
a． 响应时间<=15秒；
b． 更新处理时间<=5秒；
c． 数据的转换和传送时间<=5秒；
d． 数据等待的要求：出现相应的提示，如鼠标改变为漏斗形状，屏幕出现“正在处理…”的信息等。
3.2.3灵活性
当需求发生某些变化时，该软件系统对这些变化是否需要做出相适应的变化：
a． 操作方式上的变化：否；
b． 运行环境的变化：否；
c． 同其他软件的接口的变化：否；
d． 精度和有效时限的变化：否；
e． 计划的变化或改进：项目的开发时间延长、投入更大。
3.3输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
 
上面的条件决不只是看看而已，而是需要实实在在的去调查，去分析才能得出结果的
如果只是一头扎进去的话，我想到了出问题的时候才发会发现问题的严重性的!

Answer 26

既然大家都在谈这个问题，我也来谈谈我自己的亲身体会吧：  举个例子：我们公司是一个服装企业，我们的测试数据中
  货号表记录：84864
  库存表：286560
  库存日记帐表：752056
  
  我就不再说如：入库、出库、盘点、退货、调拨什么的单据了  当然，这只只是进销存的一块。我们公司的网络是100M的光纤，服务器就差没有买小型机了
  
  我们用的是ORACLE的数据库
  最近正好我在做一个用ACCESS数据库的客户端程序，目的就是为了加快客户端数据处理的速度，我们公司已经有了WEB端的物流管理系统，可是，数据处理的效率实在太低，达不到实用的要求，我们只好想办法在负担重的客户端用ACCESS数据库进行本地操作，对于需要交互的数据进行定时更新处理。
  如果真的需要用WEB端，我个人以为，只有在进行数据传输量不大的时候才比较实用，而进销存系统不只只是数据计算量大，而且数据传输的量也是非常大的，举个例子：  输入一张盘点单，我需要查询所有以BB%开头的，属于成品仓库的、在2003-09-04之前 ，属于A客户的仓库库存数量及金额，假设返回结果为200条，就这个查询，你想想在10万级的数据查询中得多长时间？查完了以后，你得有多大的数据量回传到客户端呢？我想最少要3分钟的时间吧。
  
 我想，如果想要做一个项目 ，你首先得弄清楚你的软件以后的运行环境
 有硬件环境及软件环境
 需求分析中：  对性能的规定
3.2.1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.2.2时间特性要求
a． 响应时间<=15秒；
b． 更新处理时间<=5秒；
c． 数据的转换和传送时间<=5秒；
d． 数据等待的要求：出现相应的提示，如鼠标改变为漏斗形状，屏幕出现“正在处理…”的信息等。
3.2.3灵活性
当需求发生某些变化时，该软件系统对这些变化是否需要做出相适应的变化：
a． 操作方式上的变化：否；
b． 运行环境的变化：否；
c． 同其他软件的接口的变化：否；
d． 精度和有效时限的变化：否；
e． 计划的变化或改进：项目的开发时间延长、投入更大。
3.3输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
 
上面的条件决不只是看看而已，而是需要实实在在的去调查，去分析才能得出结果的
如果只是一头扎进去的话，我想到了出问题的时候才发会发现问题的严重性的!

Answer 27

Drate(小虫):谢谢，看了你的这些亲身体会，我感觉到了我们打算做B/S结构的茫然性了，我们经理一意孤行，他只是想显示出做这个结构有多么多么新颖，多么吸引人。其实我也觉得做进销存系统不必把数据库放到网上，就单单从安全性来考虑就不怎么合理。因为数据本身的价值要比软件值钱的多。况且我们现在的系统想实现数据共享也可以（通过远程访问），可以实现库存上传和库存汇总，通过拨号就可以。进销存的数据量都是很大的，在查询上是极其慢的。谢谢大家的回答：）还有谁有高见么？

Answer 28

看了大家的讨论，我发现基本都赞同一点：进销存的数据量都是很大的，在查询上是极其慢的。这证明大家的思维多数还停留在C/S时代。要明白进行web数据开发就要使用web开发的思维，例如你的数据库中有数百万条记录，客户要求select *，难道你不给客户看？一次性传输到客户浏览器？显然非也。要满足这样的需求，一方面要在数据库优化上下功夫，尽量加快查询执行速度，另一方面也要选择合适的数据分页技术，要知道即使有100万条数据满足要求，客户也不可能一下子就全看到，完全可以少量多次发送，每次发送100条左右，客户按“下一页”的时候再发送下一批记录。不要讨论Delphi能不能做到的问题，想想几年前asp.net等先进技术还没有诞生的时候就有无数的大型网络数据应用在运行了，那时候人家怎么写的？不要过度迷信新技术（当然新技术是很好的，高速高效嘛）。我自己有一个共享软件作品ezService（http://www.ezService.org），已经在CSDN注册了（http://www.csdn.net/cnshare/soft/18/18634.shtm），其中的查询服务直接支持数据分页，通过指定页数就可一方面快捷的返回xml数据封包，而且与delphi合作得很好（它本身就是用Delphi 7写的），如果你或者你们公司有兴趣，可以看看。简要介绍：
1.  使用ezService开发分布式数据库应用，可以大幅度简化应用服务器的开发，无须在建立COM+/SOAP  Server应用上花费任何时间，也不需要费心管理数据库事务，只要具备熟练运用SQL的能力，理解SQL参数匹配规则即可写出复杂的分布式应用服务，使得入门级程序员也可以轻松负担服务开发任务。
2.  ezService高级服务允许按照类pascal语法规则自由书写脚本，实现复杂业务逻辑，新版本可以支持自Borland  Delphi  7导出的大量函数和对象。同时提供了对COM的直接支持，可以通过引用COM组件，与外部系统进行复杂的交互操作。
3.  ezService内核为COM+，支持连接池（connection  pooling）和对象池（object  pooling）机制，自动支持分布式事务。
4.  ezService使用ADO提供程序连接数据库管理系统，凡是提供良好的OLE-DB驱动的DBMS均可支持（目前已经在SQL  Server和Oracle  8/9上通过用户验证）。
5.  ezService使用名为ESDL（ezService定义语言）的（类似WSDL）XML发布文档，ESDL可以对外界发布ezService所开发服务的全部功能接口，使得第三方开发者也可以方便的了解服务，快速进行二次开发而无需了解服务细节。
6.  支持SOAP协议，提供一个ISAPI类型的Web  Service，一个ASP.NET  Web  Service，可以直接将服务功能发布到Internet/Intranet，无须额外编程。
7.  未授权的ezService服务具备与授权版本完全相同的功能，仅会在执行时随机锁定3个用户身份验证帐号，其他功能不受影响。
8.  由于使用了COM+/SOAP技术，ezService可以被主流开发工具轻松调用，发行版本附带了可应用于Borland  Delphi  7的一组VCL，使开发员可以迅速访问ezService服务。在Visual  Studio  .NET开发环境中也可以轻松使用类似技术。

Answer 29

Miracle()：感谢你写了这么多，我会慎重考虑的。例如你的数据库中有数百万条记录，客户要求select *，难道你不给客户看？一次性传输到客户浏览器？显然非也。要满足这样的需求，一方面要在数据库优化上下功夫，尽量加快查询执行速度，另一方面也要选择合适的数据分页技术，要知道即使有100万条数据满足要求，客户也不可能一下子就全看到，完全可以少量多次发送，每次发送100条左右，客户按“下一页”的时候再发送下一批记录。
---------------------------------------------------------------------------------
赞同！

Answer 30

用asp.net+C#+sql server 2000 大趋势拉，不是让你赶时髦，真的很不错！～