寻求较好的《连锁超市物流管理系统》的数据库设计方案.....

[亚历山大-马龙]

现在有一个课题：《连锁超市物流管理系统》，我本人查资料查了不少，以前也做过其他企业的信息管理系统，但是没有做过大型连锁企业的......所以啊，在这里请教大家，谁有经验的可以拿来讨论讨论：
我想设计一个系统，总部数据库就只能有一个了，这个是没有问题的；但是各个分店的销售数据是保存在分店本地（我还考虑了配送中心）的数据库呢，还是要上传到总部呢？如果是保存在总部数据库，那么总部服务器的工作量就太大了，数据增加速度也是非常可观的....若是保存在分店服务器（可能保存在配送中心要更好一些），那么总部如何根据销售情况（如每天的人流高峰时间、对产品包装的颜色、含量的喜好等等）来进行统一进货决策呢？
希望给点意见......

[亚历山大-马龙]

现在看来原来的设想有误：配送中心的投入巨大，看来一般地，在一个较大的区域内有一个配送中心就已经不简单........在的出这样的结论之后，系统设计就简单多了。

先在这里谢谢大家支持哦！！！！

还有一个问题：

如何解决可变列数量的问题？

eg:
运输表：
运输编号　订单编号１　订单编号２　订单编号３．．．　执行车辆１　执行车辆２．．．．
１　　　　　　０１　　　０２　　　　０３　　．．．　　０００１　　０００２．．．．　
２　　　　　　０８　　　０９　　　　１０　　．．．　　０００５　　００１０．．．．
３　　　　　　１１　　　１２　　　　１４　　．．．　　００１１　　００１６．．．．
４　　　　　　　．　　　　．　　　　　．　　．．．　　　　．　　　　　．　　．．．
５　　　　　　　．　　　　．　　　　　．　　．．．　　　　．　　　　　．　　．．．
６　　　　　　　．　　　　．　　　　　．　　．．．　　　　．　　　　　．　　．．．


是不是就将该列设置为可为空就可以了呢？觉得不太好啊。

[tangkai_boy]

这个大可以这样做。运输表只包含三个字段。

运输编号　订单编号１　 执行车辆１　
１　　　　　　０１　　　０２　　
２　　　　　　０８　　　０９　　　

只是这样就会把数据量加大。 其实也挺好的、

[以专业开发人员为伍]

呵呵，如果你认为软件就是c/s数据库，那么还能做什么呢？

分店如果要上报资料，它就访问总部上报资料服务；如果分店要下载资料，它就访问分店下载资料服务；跟数据库有什么关系呢？

[以专业开发人员为伍]

让我们随便说一个好不懂软件开发的人都可以想到的场景，假设一个在大商场的专柜，它使用一个智能手机每隔5分钟上传一次资料，或者当有短信通知时就按照短信的指引去下载资料。如果搞事业的人纠缠于程序员那种“这样做比较省事”的心思，还找出许多编程之类的“理由”，这个世界上就不会有用IT技术来取得竞争优势的企业了。

设计软件不要从程序员的思路出发。