To: fionfrankie猜也是用的这种模式，这种只适合相当小的企业信息管理模式的软件，这种模式20个表足够。很显然，你的这种做法在表里会有很多垃圾字段，当记录少时无所谓，当功能较多及记录较多时基本不具备实用性。现在大型企业主业务表一年下来的记录数能到10亿以上，你的这种做法根本不可行。当然如果总记录数只有50万条之内，这些很简单了。大型ERP一般价格从数千万到数亿不等，国产的都要数百万，就是些针对500-1000人50个点以内的小型ERP也要数十万，这些不是靠那寥寥几个表可以搞定的。当然，如果是自己接个私单做针对某些特定小型企业的ERP（应该是信息管理才对），数千元都有的做了。
两者都不是，我在一家工厂里做号称MIS的职员
create table bo_friend ( friend_id, friend_name, friend_address, .. )
create table bo_contact ( contact_id, contact_name, friend_id, ... )
create table bo_account ( account_id, friend_id, bank_info, .. )
create table bo_contract ( contract_id, account_id, contract_type [supply,customer], .. )
create table bo_product ( product_id, ... )
create table bi_contract_item ( item_id, contract_id, product_id, ... )
create table bi_contract2supply ( contract_id, supply_specialInfo,..)
create table bi_contract2customer ( contract_id, customer_specialInfo,.. )
说明:
bo_ 基本对象{friend(合作伙伴), contact(联系人), account(帐户), contract(合同), product(产品), ..}
bi_ 商务信息{contract_item(合同条目), contract2supply(供应商合同(特别)条款),contract2customer(客户合同(特别)条款)}
http://topic.csdn.net/u/20080112/14/03594998-b557-450e-840b-1d12c366b065.html
你看完那個就知道如何設計了.给CSDN留點空間,哈哈。
你的资源的提供者--下家,也即你的供应商分表存.如果:
既然客户可能也是供应商,供应商也可能是客户.
即同一个企业 companyX 可能是你们 a项服务或产品的资源提供者, 它又是你们 b项服务或产品的消费者.要么,分开. 即 companyX 有两个帐户, 分别在下家和上家两个数据库里. 这样,就是明确的划分出了上家和下家, 即 上家里的companyX与下家里的companyX没有任何联系
要么,合并, 采用更复杂的结构设计,比如引入角色及权限, 统一在一种结构里处理. 这样,不分上家和下家,无论上家下家都是你的联系人,只不过companyX 具有 上家和下家两种角色及对应的权限.
大家的说法是"这样不好分别"。我的说法是:
1. 需要区分的时候是能够区分的；区分的逻辑就在数据里，区分的UI在前台接口；
2. 为什么要区分呢? 这个合作伙伴在买我们的东西，那个合作伙伴卖给我们东西，这个那个的有什么区别？买卖的区别是在商务合同里面，是在帐户的进出帐务上；
3. 最好不要区分(站在老板的角度)；尽量将货物卖给每个可能买的人，尽量建立更多的采购渠道降低成本。
/ \
Customer Supplier
[jxwangjm]:如果分开设计，那么在处理月结时，应付帐款和应收帐款似乎必须分开处理，必须有交易单据，这在实际上来讲，有些难以理解，不过好像合起来处理，也不是很好处理
----------------------------------------------
这是另一个问题了:关于财务的表设计。-- "客户"表和财务表是分离的。
首先"客户"表保存的是"客户的信息", 客户的账户信息另外建表，一个客户可以有多于一个的账户 (如果某"客户"有多重身份，可以将不同的账户id设置为不同类型，供不同的身份使用 -- 某"客户"的销售帐户和供应帐户..)。
财务表按照财务的收支两条线的原则分表：收入表，支出表；表里当然要保持帐户信息 (当然也可以在一张表里通过类型区别然后建视图分开。) -- 这是交易记录
time and space is anyway and anyware. :)
而供应商也可以成为客户，统一在一个表有好处。
强烈合并为一个表,在代码逻辑中一个boolean值或整型值就可将其区分,方便扩展,减少表维护数量,可乐而不为,简单事情简单做!
除此之外,我把:
1.库存帐/出纳帐/往来帐/总帐/明细帐,合成了一个表;
2.货品类别/账本/地区/工序类型/会计科目/部门,合成一个表;这种方法在实践中我感到维护及扩展相当方便.特别是数据导入导出,加密,索引建立等因为表的数量少了而容易管理;
如果合成一个表，在数据库中用两个字段（是不是客户，是不是厂商）比用一个字段要好，在代码中用两个属性也会比一个属性要好，这个我也是参照别人的做法如果把厂商与客户并成一个表，从对象模型上也要把厂商与客户并成一个概念，那就是上面很多兄台所说的合作伙伴，这种改变对使用者来说，有些难度，对我来说，也有些难度1.库存帐/出纳帐/往来帐/总帐/明细帐,合成了一个表; 你不会是说库存帐与出纳帐并在一个表中吧，我刚开始以为你为你说的厂商的是库存帐与客户的库存帐并在一起，后来想想应该不是我觉得这样是不是太勉强了一点个人意见，如有不妥，请勿挂怀
我的账表结构如下:
objectType,objectId,Description,BeginQuantity,BeginMoney,AddQuantity,AddMoney,DecreaseQuantity,DecreaseMoney,EndQuantity,EndMoney这个objectId刚好能承载所有类型帐目对象,可以是货品ID/科目ID/客户ID等;以后有新帐目对象,我就不用更改表结构了.关于客户表,我设了个整型字段,用以区分不同客户类型,可以是客户/代理/外协/伙伴/供应,想加随加!
我不好意思打击他的自信心,我觉得他很勤劳,但是没有领会到VB的精髓,VB是专给懒人用的,他不可以在VB上做VC的工作，他这个程序写的容易维护就怕怕了!
其实我也写了个ERP CTP程序,前后用了5年时间,用时太长但无法子,是一个人做的功夫,不过整体结构可畏简而精了,共用了22个窗(包括登陆窗、控制台），21个表。
我还是觉得我的程序可以写的更浓缩！我现在正使用LINQ重写数据层！
看你的实际情况，但是绝大多数情况下使用同一个表，只是用一个字段进行区分此前我的设计都是用2个表，从2003年以来都用一个表，原因如下：
1、早些年一般按照客户、供应商一般可以将分类，最多有一种既是客户又是供应商的情况，所以2个表分开比较容易维护，最多部分客户分别在客户和供应商中同时维护即可2、随着经济和企业的发展，与我们发生业务往来的客户已经相当的复杂，已经不能用2个简单的表进行维护，一般包括几种可能：
A、客户 B、供应商 C、客户/供应商 D、加盟专卖店 E、所属专卖店 F、业务BU G、支付对象 H、职能部门 随着公司规模扩大，同一家集团公司发生业务，由其业务公司下单，财务公司结算、集团公司对帐这种情况越来越多，所以根本就不能以简单的的客户供应商来区分，至于加盟专卖店就不用说了，各个BU由于某些BU属于独立核算系统，不同BU直接往来也是挂帐的，所以用供应商根本不可取。
你不可能又一个新的业务往来角色就添加一个窗口添加一个界面来维护的。
一溜下来，似乎有一个用20来个窗口实现ERP的哥们，如果说ERP有20来种窗口模式这不为过（譬如报价单、订单、生产单、工单、出货单、退货单、入库单、出库单基本是同一个模式），如果20来个窗口能搞定就NB了，除非是纯粹资料记录模式，否则根本没戏！一个完整的比较通用的制造行业的小型ERP一般在400-800个表之间，象SAP、ORACLE、BAAN等大型ERP都有数千个表，靠20来个窗口无法想象怎么能完成。当然，仔细看下来，里面的窗口按照窗口模式分类也就是20来种，甚至没有这么多。祝楼主好运。
客户和供应商是分开的，
而且根据不同的目的，又包括了很多表
例如：
客户/供应商基本数据
客户/供应商主数据
客户/供应商账类数据
客户/供应商信贷数据可能根据具体的软件规模，具体分析了
我设计表没有按照最优化,而是采用兼容模式,所以程序用的表很少.我用一个企业目录表承载了企业所有有关的标准命名条目,用一个类别表承载了所有分类,用一个单据表和一个单据明细表承载了所有单据(销订,采订,工单,完工,收货,发货,外发,凭证,收款,付款,借款...),一个信息表承载了所有一般化资料,一个账表承载了所有账目,一个客户表...,一个价目表...;
总结下来表就只有20个.
我设计窗体时也采取兼容方式,例如不同单据就是不同列显示而矣,就一个窗体可以满足;
我设计程序真的是超级懒汉,能简的则简,可以不用就不用,我没有使用存储过程,能合并则合并,不过我设计索引是很细心的!
有时我觉得我是做对了,因为我的维护工作很容易驾驭;功能算不上最强,但由于表少窗少模块少,统一性增强了,就是容易对权限控制,容易加密,容易导入导出转换格式!
上千个表?听了就怕,恐怖极了,对于我这个无人无物的小角色,这等工作还是留给你们这类吃大茶饭的同志吧!
我这半ERP系统在企业已运行5年,效率依然不断,得益于索引设计和数据时段划分,数据都可以导出导入,可以新老账套交接,这些方法解决了海量数据存取的问题.几年下来的数据就只几百MB,我设计时已用VM系统模疑测试过它,结合SQL SERVER技术性能估计承载过亿记录不成问题,按目前状况我想它能继续撑下去!要不然客户还能升级硬件,使用群集!标准化数据好坏各异,好的是节约空间,网络传递快速.坏在代码复杂了,我设计表时也有一些原则:
1.不使用图片或大文本字段,用路径位置替代之;
2.运用精确数据类型;
3.尽量保持数据包往返较少,大吞大吐为上;
4.不乱合并数据表,不用联集查询;
5.读写数据前进行预处理及优化;
重要的微软已做了,我只关心的性能平行点!
我的小软件实现了企业主要管理需求以及一些的特别想法,它是不全面的,但代表我对程序设计的爱好,实践管理方法的追求,只要有人愿意用我的,我就跟他摸着石头过河...
一个个问题被解决了,我会最感满足!
望先知者能不啬赐教我等后生之辈为谢!
程序大了自然不同，客户自然也不会随意修改，很多情况下并不是要改程序，而是要客户改工作流程。
这是小型ERP和大型ERP实施起来最本质的不同，当然开发也同样不同。ERP从最早的MPS，到MRP、MRPII、ERP，到目前所谓的eERP，变化越来越多，概念越来越翻新，但是本质变化并不大。
ERP从制造业开始，发展到服务业，以及目前衍生出的物流行业，以及目前全套整合的供应链领域，一切在前进，一切都在摸索。
目前SAP、BAAN、Oracle走在了前面。当软件的规模到一定程度以后，很多东西的做法会完全不同。
这也是目前很多大型数据库(单表行数>100亿)比较少用SQLServer的一种解释，当然原因有很多，你说SQLServer在这种情况下真的比Oracle差，真的未必。同样，Informix说不定比Oracle好很多，但是一种习惯性思维在延续，所以选择Oracle的居多，因为没有那个系统设计人员会去冒这个险，除非得到MS的大力支持。目前的主流数据库中当记录数在300万以内只要建立了所以，数据库设计的不是太垃圾，效率几乎没什么不同，记录数在10万之内的时候Oracle还不如VFP数据库快。那么你试一下在你的数据库中产生10亿条记录，效率真的就是那样吗？说了这么多，现在产生了几个问题：
1、做软件的目的是什么？
2、你为什么去做软件？
3、软件给你带来了什么？
4、做软件让你失去了什么？
A: 为所在企业服务 / 为所在企业的客户服务 / 为未来的客户服务Q2、你为什么去做软件？
A: 完成企业交给的任务 / 开发一种通用产品使之成为将来的销售产品或服务工具Q3、软件给你带来了什么？
A: 薪资、奖金、经验、(未来的客户)Q4、做软件让你失去了什么？
A: 时间