C
cool_cool
Unregistered / Unconfirmed
GUEST, unregistred user!
我觉得应对进货单单独做一个表，这样可以用来反应进货情况，可能在客户使用时有用
O
oceanwave
Unregistered / Unconfirmed
GUEST, unregistred user!
所有单据单独做表，好处是：一、速度；二、数据的纯粹性；三、与概念相统一。反正好
就是了。
另外怎么多人给出概念与细节方面的建议与意见了，我觉得更多的东西你应该自己深入的
体会与思考，而且应该是由浅至深，不要想一步到位。而且对一个结构完全的进销存软件
来说，它并是一个人在短期能完成的，所以更多需要的是耐心与细心。
希望你能在一个阶段内好好的去体会这些东西，在比较独立的状态下去解决问题。如果你
太依赖大富翁上给你的现成答案的话，到了后面，困难越来越大。很多问题，已经很少人
可以给你回答的时候，你就无法继续。如果你一开始就有自己的思考方式与能力的时候，
当遇到真正的困难，大家的讨论，那怕没有真正的答案，都会给你很大的启发，这样，我
想你会进步的更快。
最后，祝你成功！
各位参与讨论的同道中人，可以与我用OICQ交流：6341782
电邮：i2346@hotmail.com
这个问题可以暂时结束了。留下的问题，让大家去思考吧！[
]
就是了。
另外怎么多人给出概念与细节方面的建议与意见了，我觉得更多的东西你应该自己深入的
体会与思考，而且应该是由浅至深，不要想一步到位。而且对一个结构完全的进销存软件
来说，它并是一个人在短期能完成的，所以更多需要的是耐心与细心。
希望你能在一个阶段内好好的去体会这些东西，在比较独立的状态下去解决问题。如果你
太依赖大富翁上给你的现成答案的话，到了后面，困难越来越大。很多问题，已经很少人
可以给你回答的时候，你就无法继续。如果你一开始就有自己的思考方式与能力的时候，
当遇到真正的困难，大家的讨论，那怕没有真正的答案，都会给你很大的启发，这样，我
想你会进步的更快。
最后，祝你成功！
各位参与讨论的同道中人，可以与我用OICQ交流：6341782
电邮：i2346@hotmail.com
这个问题可以暂时结束了。留下的问题，让大家去思考吧！[
]
W
weiweiHU
Unregistered / Unconfirmed
GUEST, unregistred user!
toceanwave
你是重庆人吧？我怎么觉得你说的就是我们公司的软件一样，你是[SUN]或是[ZHAO]
啊，如果不是就怪了！！！！！
ceanwave你是重庆人吧？我怎么觉得你说的就是我们公司的软件一样，你是[SUN]或是[ZHAO]
啊，如果不是就怪了！！！！！
L
LiWen
Unregistered / Unconfirmed
GUEST, unregistred user!
关注
O
oceanwave
Unregistered / Unconfirmed
GUEST, unregistred user!
我不是重庆人，重庆还没去过。我说的东西都是我在工作实践中所领悟、归纳的。
to zheng:
不好意思，没注意到你的三个问题，虽然上面已稍做回答，现回答如下：
1.用不用库存表在于三个条件：一是在于你对单据向库存提交数据的过程是否处理妥当，
不能做好错误及异常处理，库存就会出问题，而且找问题就够你头痛的了，库存表的问题，
并不是找到那个产品出现去改库存数字就可以了，而是要由修改单据而修正库存数量，这个
关系你一定要明白。二是单据的数据量是否巨大，如果数据量非常大，当然对表的访问肯定
是比查询要快得多，但一般的小企业，做好清转工作后，单据的数据量并不大。三是你对
SQL的熟悉程度，毕竟写SQL有点烦人。以上三点，你自己权衡一下，灵活应用了。
对了，我忽然想起来，我后来为什么不选用库存表的原因，因为我当初做的程序是有分仓的
而每个仓库有一千多个货品，14个仓库，那就有一万多条记录。而这一万多条记录只会是只
增不减，所以操作速度受影响。我说得不太清楚，但大概是这个意思。但我也不一定不采用
库存表的方式，只是要看什么情况下了。写程序就是要灵活。呵呵
2.各单据的主从表都要独立，理由我前面都说过了，这一点，在很多软件的编写中都是一个
好的习惯。建议你在建数据库前，好好理解一下数据库的五个范式，（算了，后面我再抄一
抄关于范式的东东吧）
3.关于软件呢，不是我小气，就象源码连我的合作伙伴我也不给的一样，各人有各人的编码
技巧。我可以把我的编程思想都告诉你，但如果连源码都给你的话，你就失去了自己思考的
机会。毕竟这些东东都是卖钱的，也意味着每个人的劳动成果。希望你能理解。当然，我会
继续回答你的问题罗，嘿嘿。对于管家婆之类的软件，我是觉得你不必去看，因为它顶多给
你一个进销存软件的流程结构，而这些流程结构我在上面已经说过了。你越去看它，就会给
自己定越大的目标，也就越难完成，这样往往是半途而废，所以你还是从只有一个进货单，
一个出货单的基础开始做起，循序渐进，这样，你以后也可以一个月写六七个进销存了，就
象“庖丁解牛”是不是？呵呵。[]
希望以上的回答，能给你质上的帮助，而不只是面上的参考而已。
to zheng:
不好意思，没注意到你的三个问题，虽然上面已稍做回答，现回答如下：
1.用不用库存表在于三个条件：一是在于你对单据向库存提交数据的过程是否处理妥当，
不能做好错误及异常处理，库存就会出问题，而且找问题就够你头痛的了，库存表的问题，
并不是找到那个产品出现去改库存数字就可以了，而是要由修改单据而修正库存数量，这个
关系你一定要明白。二是单据的数据量是否巨大，如果数据量非常大，当然对表的访问肯定
是比查询要快得多，但一般的小企业，做好清转工作后，单据的数据量并不大。三是你对
SQL的熟悉程度，毕竟写SQL有点烦人。以上三点，你自己权衡一下，灵活应用了。
对了，我忽然想起来，我后来为什么不选用库存表的原因，因为我当初做的程序是有分仓的
而每个仓库有一千多个货品，14个仓库，那就有一万多条记录。而这一万多条记录只会是只
增不减，所以操作速度受影响。我说得不太清楚，但大概是这个意思。但我也不一定不采用
库存表的方式，只是要看什么情况下了。写程序就是要灵活。呵呵
2.各单据的主从表都要独立，理由我前面都说过了，这一点，在很多软件的编写中都是一个
好的习惯。建议你在建数据库前，好好理解一下数据库的五个范式，（算了，后面我再抄一
抄关于范式的东东吧）
3.关于软件呢，不是我小气，就象源码连我的合作伙伴我也不给的一样，各人有各人的编码
技巧。我可以把我的编程思想都告诉你，但如果连源码都给你的话，你就失去了自己思考的
机会。毕竟这些东东都是卖钱的，也意味着每个人的劳动成果。希望你能理解。当然，我会
继续回答你的问题罗，嘿嘿。对于管家婆之类的软件，我是觉得你不必去看，因为它顶多给
你一个进销存软件的流程结构，而这些流程结构我在上面已经说过了。你越去看它，就会给
自己定越大的目标，也就越难完成，这样往往是半途而废，所以你还是从只有一个进货单，
一个出货单的基础开始做起，循序渐进，这样，你以后也可以一个月写六七个进销存了，就
象“庖丁解牛”是不是？呵呵。[
]希望以上的回答，能给你质上的帮助，而不只是面上的参考而已。
O
oceanwave
Unregistered / Unconfirmed
GUEST, unregistred user!
关于数据库设计：
数据库设计的关键解决方法是归一化。从单一数据库中将创建一系列表和字段，各表之间
通过主关键字和外部关键字字相互关联，而表中的数据是恰当结构化的。
归一化包括大约20条规则，每一条都依赖于其前一条，使数据更加结构化。例如，依据
字母顺序排序的列表可以说是非归一化的。当应用归一化的第一条规则后数据库应该“满足
第一范式”，而应用完第二、第三、第四条规则后，数据库应该满足第四范式。
就实际而言，大部分归一化的数据库都不超过第三范式，因此就有一些争论，即超过第
六、七范式的规则在日常操作中是否有实际意义。但一般确实很难超出第五范式。
以下是各个范式：
[blue]第一范式 将重复或者多值的字段移到另一个表中[/blue]
这个道理实际都明白，就象分仓的结构一样，仓库有单独的仓库表，产品有单独的产品表
而，期初库存表中，这两个表就是它的父表。对期初库存表中仓库和产品这两个有重复及多值
的字段在仓库和产品表中是唯一的主关键字。
[blue]第二范式 移走不依赖于整个主关键字的字段[/blue]
这是表现主键字的精简性，比如单据的明细表中，应该是表头ID、产品号做为关键字，
如果把产品名也加入主关键字的组合话，就违反了这个范式，因为产品名并不依赖于整个
主关键字，当产品号确定的时候，产品名就在产品表中确定对应了。
[blue]第三范式 移走依赖于其他的非关键字字段的字段[/blue]
就象，你在单据的表头中把客户的地址、电话也做在里面一样，地址电话也是依赖于
客户名这个在单据表头是的非关键字段。
[blue]第四范式 将主关键字的独立多值部分移到多个新的父实体中[/blue]
首要的是，你在使用多字段组成的主关键字时，并不想从独立的可能含有多个值的字段
中进行选择，简单的说，你不想造成这样一种情况L在一个字段中改变数据时，还要改变另
一个字段中的数据。如果你使用单字段的主关键字，这就不是问题了，而且一量你的表满足
第三范式也就满足了第四范式。
[blue]第五范式 将以成对方式循环依赖的主关键字（出现在具有3-4个字段的组合关键字中）移到
三个或更多的父表中[/blue]
这一规则从某种意义上来产是第四范式的一个拓展。
归一化工作的意义：
一、存储空间最小化的需求
二、消除数据的不一致性
三、最不化更新和删除时的问题
四、结构化程度最高
数据库设计的关键解决方法是归一化。从单一数据库中将创建一系列表和字段，各表之间
通过主关键字和外部关键字字相互关联，而表中的数据是恰当结构化的。
归一化包括大约20条规则，每一条都依赖于其前一条，使数据更加结构化。例如，依据
字母顺序排序的列表可以说是非归一化的。当应用归一化的第一条规则后数据库应该“满足
第一范式”，而应用完第二、第三、第四条规则后，数据库应该满足第四范式。
就实际而言，大部分归一化的数据库都不超过第三范式，因此就有一些争论，即超过第
六、七范式的规则在日常操作中是否有实际意义。但一般确实很难超出第五范式。
以下是各个范式：
[blue]第一范式 将重复或者多值的字段移到另一个表中[/blue]
这个道理实际都明白，就象分仓的结构一样，仓库有单独的仓库表，产品有单独的产品表
而，期初库存表中，这两个表就是它的父表。对期初库存表中仓库和产品这两个有重复及多值
的字段在仓库和产品表中是唯一的主关键字。
[blue]第二范式 移走不依赖于整个主关键字的字段[/blue]
这是表现主键字的精简性，比如单据的明细表中，应该是表头ID、产品号做为关键字，
如果把产品名也加入主关键字的组合话，就违反了这个范式，因为产品名并不依赖于整个
主关键字，当产品号确定的时候，产品名就在产品表中确定对应了。
[blue]第三范式 移走依赖于其他的非关键字字段的字段[/blue]
就象，你在单据的表头中把客户的地址、电话也做在里面一样，地址电话也是依赖于
客户名这个在单据表头是的非关键字段。
[blue]第四范式 将主关键字的独立多值部分移到多个新的父实体中[/blue]
首要的是，你在使用多字段组成的主关键字时，并不想从独立的可能含有多个值的字段
中进行选择，简单的说，你不想造成这样一种情况L在一个字段中改变数据时，还要改变另
一个字段中的数据。如果你使用单字段的主关键字，这就不是问题了，而且一量你的表满足
第三范式也就满足了第四范式。
[blue]第五范式 将以成对方式循环依赖的主关键字（出现在具有3-4个字段的组合关键字中）移到
三个或更多的父表中[/blue]
这一规则从某种意义上来产是第四范式的一个拓展。
归一化工作的意义：
一、存储空间最小化的需求
二、消除数据的不一致性
三、最不化更新和删除时的问题
四、结构化程度最高
D
dsmiao
Unregistered / Unconfirmed
GUEST, unregistred user!
关注
C
chassis
Unregistered / Unconfirmed
GUEST, unregistred user!
gz
W
weiweiHU
Unregistered / Unconfirmed
GUEST, unregistred user!
to oceanwave
昨天我真的以为你是我们公司的人，我们也是做JXC的，从DELPHI1.0开始，
你说的单据，流程图以及往来帐款的生成方式，库存的生成方式和我们一样，
你的：[对库存表的增减的问题，就会影响库存表的正确性，
所以我的库存结果是用查询做出的来]
这个问题我们也头疼，我也是用单据汇总来做的”包括往来帐款“，比如通过出库单，
调拨单，进库单等，但是当数据量很大时汇总就时间较长了，我们能否讨论一下这个问题
怎样解决？？？[我看了你的以上库结构和我们的差不多，主、明细表单据]细表用GRID。
我们从不在库里用存储过程、触发之类的东东，因为如果库出了问题很麻烦。
昨天我真的以为你是我们公司的人，我们也是做JXC的，从DELPHI1.0开始，
你说的单据，流程图以及往来帐款的生成方式，库存的生成方式和我们一样，
你的：[对库存表的增减的问题，就会影响库存表的正确性，
所以我的库存结果是用查询做出的来]
这个问题我们也头疼，我也是用单据汇总来做的”包括往来帐款“，比如通过出库单，
调拨单，进库单等，但是当数据量很大时汇总就时间较长了，我们能否讨论一下这个问题
怎样解决？？？[我看了你的以上库结构和我们的差不多，主、明细表单据]细表用GRID。
我们从不在库里用存储过程、触发之类的东东，因为如果库出了问题很麻烦。
O
oceanwave
Unregistered / Unconfirmed
GUEST, unregistred user!
to weiweiHU:
我前面说过，关键是尽量的分类结果，合理地限制结果集的大小。比如对于某一单据
的列表，可以预先给定一个日期段，让结果集控制在一个合理的日期范围内。因为毕竟使
用者不会经常进行大日期范围的查询。
还有就是我说过的定期清转，季度、年度的清转使单据数据控制在一个相对比较小的
范围内，查询当然也会快得多。关键是系统的灵活性。查询事项有轻有重，有缓有急，很
难做到面面俱到，所以主要考虑使用者的日常使用习惯，其它的不常用的功能让使用去适
应，这样原先使用者不习惯的事情，在潜意识的强迫使用下也会变成他们的习惯行为。
做一个软件，特别是进销存软件要考虑很多东西：商业规则、管理行为、使用习惯、
客户心理、代码技巧、行业惯例等等。把这种种因素权衡、综合、协调，这样才能把技术
上不稳定、不容易实现的细节控制住，并消化掉。
我前面说过，关键是尽量的分类结果，合理地限制结果集的大小。比如对于某一单据
的列表，可以预先给定一个日期段，让结果集控制在一个合理的日期范围内。因为毕竟使
用者不会经常进行大日期范围的查询。
还有就是我说过的定期清转，季度、年度的清转使单据数据控制在一个相对比较小的
范围内，查询当然也会快得多。关键是系统的灵活性。查询事项有轻有重，有缓有急，很
难做到面面俱到，所以主要考虑使用者的日常使用习惯，其它的不常用的功能让使用去适
应，这样原先使用者不习惯的事情，在潜意识的强迫使用下也会变成他们的习惯行为。
做一个软件，特别是进销存软件要考虑很多东西：商业规则、管理行为、使用习惯、
客户心理、代码技巧、行业惯例等等。把这种种因素权衡、综合、协调，这样才能把技术
上不稳定、不容易实现的细节控制住，并消化掉。
P
pclover
Unregistered / Unconfirmed
GUEST, unregistred user!
关于范式，我想提出一点我的看法：
现在跟十几年前相比，存储空间已经不是需要注意的地方了，
适当的润余对报表，查询，以及DSS都有好处。
举例来说，把货币，单位同时写入收货单，这样，做报表时不必连接这两个表了
现在跟十几年前相比，存储空间已经不是需要注意的地方了，
适当的润余对报表，查询，以及DSS都有好处。
举例来说，把货币，单位同时写入收货单，这样，做报表时不必连接这两个表了
T
T18sc
Unregistered / Unconfirmed
GUEST, unregistred user!
在日常的操作中你们用什么保存数据，比如说新增的一张销售单，对该销售单的操作是
直接操作销售记录主表和明细表，（这样数据量大了会很慢）
还是用StringGrid保存当前数据，待提交该表单时将该单数据保存至销售记录主表和明细表
管家婆好象是这么作的。
还是用一个临时表，待提交该表单时将该单数据保存至销售记录主表和明细表，我的
进销存是这么作的，但基于BDE好办，在本地建几个Pdox表。基于ADO如何作呢？尤其是用SQL数据库，把
临时表都建在后台不好吧。
有人建议用 Cach update不知有人用过吗，好用吗。
各位是如何作的呢，尤其是用SQL数据库的。
我的Email: myquery@1298.net 多交几个朋友[]
直接操作销售记录主表和明细表，（这样数据量大了会很慢）
还是用StringGrid保存当前数据，待提交该表单时将该单数据保存至销售记录主表和明细表
管家婆好象是这么作的。
还是用一个临时表，待提交该表单时将该单数据保存至销售记录主表和明细表，我的
进销存是这么作的，但基于BDE好办，在本地建几个Pdox表。基于ADO如何作呢？尤其是用SQL数据库，把
临时表都建在后台不好吧。
有人建议用 Cach update不知有人用过吗，好用吗。
各位是如何作的呢，尤其是用SQL数据库的。
我的Email: myquery@1298.net 多交几个朋友[
]
O
oceanwave
Unregistered / Unconfirmed
GUEST, unregistred user!
凡事不是绝对，如果有足够的理由，也可以提出反归一化的。
但你说的把货币，单位同时写入收货单，这就要注意，特别是单位，因为对应的货品的量
级的判断及计算是有差别的。拿个例子来说，我在做产品表的时候，部分字段设置是这样
的：
产品号|品名|型号|规格|单位|单价……
也就是说只要各产品的品名、型号、规格、单位中有一个不一样就构成一个不同的产品号
也可说可能品名、型号、规格相同，但因为量级不同（也许是按箱、按件计量）反映的单
价也不同。如果把单位放到单据表中，库存的计算就是个问题，就存在一个量级差。
所以数据库越大，数据量越大就要尽量的在大范围采用归一化。
但在局部因为查询的需要，可以采用反归一化。考虑的步骤应该是：数据的安全性-->数据
的灵活性-->数据的方便性……
关于表的提交，我想BDE的CACHEUPDATE，ADO的BATCHUPDATE都是应该用的。特别是MASTER/
DETAIL表有提交先后的问题，所以CACHEUPDATE能解决很多问题，也能提高速度和数据安全
性。关于BDE的处理方式，DELPHI自带的MASTAPP例程有仔细的说明。
说一个题外话，我是强烈建议大家多看看DELPHI的例程，都写得很经典，不说它们有多完善
但其编程思想的启发是非常适合初学者的。[]
但你说的把货币，单位同时写入收货单，这就要注意，特别是单位，因为对应的货品的量
级的判断及计算是有差别的。拿个例子来说，我在做产品表的时候，部分字段设置是这样
的：
产品号|品名|型号|规格|单位|单价……
也就是说只要各产品的品名、型号、规格、单位中有一个不一样就构成一个不同的产品号
也可说可能品名、型号、规格相同，但因为量级不同（也许是按箱、按件计量）反映的单
价也不同。如果把单位放到单据表中，库存的计算就是个问题，就存在一个量级差。
所以数据库越大，数据量越大就要尽量的在大范围采用归一化。
但在局部因为查询的需要，可以采用反归一化。考虑的步骤应该是：数据的安全性-->数据
的灵活性-->数据的方便性……
关于表的提交，我想BDE的CACHEUPDATE，ADO的BATCHUPDATE都是应该用的。特别是MASTER/
DETAIL表有提交先后的问题，所以CACHEUPDATE能解决很多问题，也能提高速度和数据安全
性。关于BDE的处理方式，DELPHI自带的MASTAPP例程有仔细的说明。
说一个题外话，我是强烈建议大家多看看DELPHI的例程，都写得很经典，不说它们有多完善
但其编程思想的启发是非常适合初学者的。[
]
W
weiweiHU
Unregistered / Unconfirmed
GUEST, unregistred user!
to oceanwave
正如你说的，我汇总时是按期间[1--31号或15--14号]，以前问题好象不大，最近做了
一家客户数据量特大，所以汇总起来就。。，但这虽然保
险，我还是认为这不是最好的，应该可以有好的方法解决，
我们的库存表：期间|货号|仓库|数量
顺便问你：你用库存表吗？全靠查询生成？
能认识你这样的同行[JXC]很高兴！其实[JXC]在很多企业是他们的核心。
正如你说的，我汇总时是按期间[1--31号或15--14号]，以前问题好象不大，最近做了
一家客户数据量特大，所以汇总起来就。。，但这虽然保
险，我还是认为这不是最好的，应该可以有好的方法解决，
我们的库存表：期间|货号|仓库|数量
顺便问你：你用库存表吗？全靠查询生成？
能认识你这样的同行[JXC]很高兴！其实[JXC]在很多企业是他们的核心。
O
oceanwave
Unregistered / Unconfirmed
GUEST, unregistred user!
to weiweiHU:
如果数据量大，单用库存表的方式其实加快不了多少速度，不信你试试。我倒觉得在
数据量大的情况下，一定要采用大型数据库，比如是SQL SERVER，并采用存储过程的方式
做查询。
我有期初库存表，但一般不做实时性的库存表，只用查询实现。但不是绝对不用，关
键看实际需要了。
还有，我只能算是你们半个同行，我在几个月前才真正做进销存软件，在此前我是外资
公司的营销、行政主管。做进销存只是我的爱好兼外快，更只是我想把我领会的管理概念
与信息化技术进行结合。所以我在流程与概念上的理解会比技术细节上要多点儿。
而这几个月来，我已经开发了十几个相关的软件，恐怖吧！前面有几个月时间是研究，而
在后面的三个月内每月平均做四个。软件不一定做得成熟，但在这么高频率的实作中，发
现了很多问题，也解决了很多问题。俗话说“熟能生巧”，我想光想是没有用的，多从基
础性的细节做起，在实践的过程找问题，解决问题，进步才会快。
谢谢！大家鼓掌（西红柿，鸡蛋#$&%)#*@)$*，我闪，我闪，嘿嘿[]）
如果数据量大，单用库存表的方式其实加快不了多少速度，不信你试试。我倒觉得在
数据量大的情况下，一定要采用大型数据库，比如是SQL SERVER，并采用存储过程的方式
做查询。
我有期初库存表，但一般不做实时性的库存表，只用查询实现。但不是绝对不用，关
键看实际需要了。
还有，我只能算是你们半个同行，我在几个月前才真正做进销存软件，在此前我是外资
公司的营销、行政主管。做进销存只是我的爱好兼外快，更只是我想把我领会的管理概念
与信息化技术进行结合。所以我在流程与概念上的理解会比技术细节上要多点儿。
而这几个月来，我已经开发了十几个相关的软件，恐怖吧！前面有几个月时间是研究，而
在后面的三个月内每月平均做四个。软件不一定做得成熟，但在这么高频率的实作中，发
现了很多问题，也解决了很多问题。俗话说“熟能生巧”，我想光想是没有用的，多从基
础性的细节做起，在实践的过程找问题，解决问题，进步才会快。
谢谢！大家鼓掌（西红柿，鸡蛋#$&%)#*@)$*，我闪，我闪，嘿嘿[
]）
X
xiaoyu_online
Unregistered / Unconfirmed
GUEST, unregistred user!
插两句，最近一段时间，受朋友的委托，我也在做关于JXC的系统，所以对大家的讨论比较留心
不过我没有这么快，我还在系统分析，至今还只是分别画出了物流图，资金流图还没有画出来。
更别谈物流和资金流的合并图。看了一下前面的两张图：
http://www.afanti.net/jxc/images/lcmain.jpg，其实是我们最终期望的整个系统的结构，但是太
抽象。
http://www.5432i.com/manageflow.gif，是个物流图，还没有和资金流结合在一起。
事实上就我个人认为JXC系统其实就是传统商业会计系统的一个扩展，因为它不仅包含了资金流还有物流。
这是最麻烦的地方，首先没有理论指导，其次没有现成的例子可供学习，大家都在自己摸索，我看了
几个JXC软件，都想把物流和资金流做好，都做的不匝地，ERP对于我们来说是个神话，我们需要的是具有
中国特色的JXC，我看了看讨论，大部分都在说细节。我有不同的意见，JXC的用户关心的是系统的安全性
和准确性，再是便捷性，这样对整个系统结构的完整和一致性提出了要求。所以，我建议大家能不能首先
来讨论一下整个JXC系统的设计。关键是物流和资金流如何更好的结合在一起。至于细节我们可以在具体
设计的时候，还讨论，各位认为呢？
不过我没有这么快，我还在系统分析，至今还只是分别画出了物流图，资金流图还没有画出来。
更别谈物流和资金流的合并图。看了一下前面的两张图：
http://www.afanti.net/jxc/images/lcmain.jpg，其实是我们最终期望的整个系统的结构，但是太
抽象。
http://www.5432i.com/manageflow.gif，是个物流图，还没有和资金流结合在一起。
事实上就我个人认为JXC系统其实就是传统商业会计系统的一个扩展，因为它不仅包含了资金流还有物流。
这是最麻烦的地方，首先没有理论指导，其次没有现成的例子可供学习，大家都在自己摸索，我看了
几个JXC软件，都想把物流和资金流做好，都做的不匝地，ERP对于我们来说是个神话，我们需要的是具有
中国特色的JXC，我看了看讨论，大部分都在说细节。我有不同的意见，JXC的用户关心的是系统的安全性
和准确性，再是便捷性，这样对整个系统结构的完整和一致性提出了要求。所以，我建议大家能不能首先
来讨论一下整个JXC系统的设计。关键是物流和资金流如何更好的结合在一起。至于细节我们可以在具体
设计的时候，还讨论，各位认为呢？
W
weiweiHU
Unregistered / Unconfirmed
GUEST, unregistred user!
oceanwave：我一直用SQL SERVER6.5到现在7.0
你只做了几个月！能有此功底已不错，我们做了5-6年了，涉及很多行业，我也知道软件的
好坏关键是业务规则是否熟悉，所以用你以往的经验应该会写出好东西，一个月写四个我想
和我一样到后来只是改四个出来而已
JXC里的东西不少，我们从门店版到 物料[BOM]-生产[工艺]
-成品-客户库存 其实已经类似MRP||了，但中间还是碰到一些问题，有时间的话
大家EMAIL聊聊：lijiawei888@sohu.com
你只做了几个月！能有此功底已不错，我们做了5-6年了，涉及很多行业，我也知道软件的
好坏关键是业务规则是否熟悉，所以用你以往的经验应该会写出好东西，一个月写四个我想
和我一样到后来只是改四个出来而已
JXC里的东西不少，我们从门店版到 物料[BOM]-生产[工艺]
-成品-客户库存 其实已经类似MRP||了，但中间还是碰到一些问题，有时间的话
大家EMAIL聊聊：lijiawei888@sohu.com
W
weiweiHU
Unregistered / Unconfirmed
GUEST, unregistred user!
to xiaoyu_online
资金流其实不用担心，你有[进]的单据，就应该生成应付款和付款，[出]就会生成
应收款和收款，调拨单和领用没有资金概验，如果有按[进]或[出]解决
资金流其实不用担心，你有[进]的单据，就应该生成应付款和付款，[出]就会生成
应收款和收款，调拨单和领用没有资金概验，如果有按[进]或[出]解决
D
davidlon
Unregistered / Unconfirmed
GUEST, unregistred user!
现在硬盘那么大，可以用空间争取时间
用范式就太死板了
用范式就太死板了
O
oceanwave
Unregistered / Unconfirmed
GUEST, unregistred user!
我上面已经说过，范式的归一化，和反归一化是并存的。可以根据实际需求灵活应用，但
范式应该是大范围存在的，反归一化在一些提高效率和特殊要求的完善方法。好的程序最
忌諱的是死板，规范与灵活相互弥补不足才能写出好程序
范式应该是大范围存在的，反归一化在一些提高效率和特殊要求的完善方法。好的程序最
忌諱的是死板，规范与灵活相互弥补不足才能写出好程序