[请教]供应商与客户分表设计与并为一个表设计的优劣比较
供应商与客户的基本资料来讲，有很多共同点，是合成一个表设计好，还是分开来设计好？
当然，各有优缺点，希望大家能说出具体的优缺点。
[解决办法]
供应商和客户在数据关系模型中属于两个独立的对象，建议分别建表。
[解决办法]
还是分开的好,除非楼主不准备区分他们.
[解决办法]
如果，你的供应商与客户都不少，那就分开，理由是供应商与客户虽然有很多共同点，毕竟是两个事物，区别是很多的，分开以后的表关系可以简单清楚些
[解决办法]
你是供应商的客户,你还是客户的供应商.
[解决办法]
看系统大小和影响这些表的相关数据
如果操作比较频繁，建议分开
如果操作不是很多而且很多信息既是客户又是供应商最好合并
[解决办法]
供应商、客户：企业合作伙伴, 交易账户上区分：供应商、客户
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(客户合同(特别)条款)}
[解决办法]
上面是个人设计。允许批评，欢迎探讨
[解决办法]
建议区分开 分开建表
至于共同点 楼主可以吧这些共同点建到其中一个表里面去
[解决办法]
在工作中，我一直也是按照分类分别建表的。但一次偶然的机会见到了一个系统，在一个表(friend)里存放供应商、客户、代理...等不同的信息。琢磨后，深以为然。其实一个活跃的企业与它的合作伙伴之间的关系也是很活跃的。
[解决办法]
建议区分开 分开建表
[解决办法]
建议：
http://topic.csdn.net/u/20080112/14/03594998-b557-450e-840b-1d12c366b065.html
你看完那個就知道如何設計了.给CSDN留點空間,哈哈。
[解决办法]
你们的服务的使用者--上家 ,也即你的客户
你的资源的提供者--下家,也即你的供应商
分表存.
如果:
既然客户可能也是供应商,供应商也可能是客户.
即同一个企业 companyX 可能是你们 a项服务或产品的资源提供者, 它又是你们 b项服务或产品的消费者.
要么,分开. 即 companyX 有两个帐户, 分别在下家和上家两个数据库里. 这样,就是明确的划分出了上家和下家, 即 上家里的companyX与下家里的companyX没有任何联系
要么,合并, 采用更复杂的结构设计,比如引入角色及权限, 统一在一种结构里处理. 这样,不分上家和下家,无论上家下家都是你的联系人,只不过companyX 具有 上家和下家两种角色及对应的权限.
[解决办法]
若分开,设计简单,实现容易,但用户体验不好.
若合并,反之.
[解决办法]
十分重要的因素要考虑清楚: 应用环境及需求。
一些应用系统的使用者在其工作场景中，主要是面向最终(个人)用户的[--场景1]，还是与企业单位交互的[--场景2]？
(通常而言供应商的身份是企业)。
如果在场景1中应用，其实“客户”-“供应商”的共性并不多，将他们分开可以简化问题，更便于业务逻辑的思考。
如果在场景2中应用，业主的业务十分稳定，“客户”-“供应商”的角色难得转换，将他们分开既没问题，也为无不便；将两种角色视为合作伙伴的临时属性的方法需要先仔细设计好系统结构框架(毕竟和人们在常见的业务模式下如此操作者不多)。
如果业主的业务十分活跃，客户-供应商的角色就会经常变换，那么设计好的"合作伙伴"关系能更稳定可靠。
[解决办法]
太遗憾了,又与楼上的观点雷同.
ps:我的表达能力欠佳
[解决办法]
分开存
[解决办法]
星星: 是我高兴：找到一个同志，只是这次比你晚了1:02秒
------解决方案--------------------
to time_spac:
...
to 楼主
你的作法只是简化了一些表的设计,但没有从根本上解决你的业务上用户角色的转化问题.
即 compayX 还是存在 客户主表.
compayY 还是存在 供应商主表.
附加信息,比如联系电话,地址之类的存放在了 附加表,共用
那么 companyX 还只是客户. company还只是供应商.
[解决办法]
这种合并（客户+供应商==>合作伙伴）其实是设计理念的东西，是现实世界的抽象归纳，是事物的本质。所以我喜欢。
大家的说法是"这样不好分别"。我的说法是:
1. 需要区分的时候是能够区分的；区分的逻辑就在数据里，区分的UI在前台接口；
2. 为什么要区分呢? 这个合作伙伴在买我们的东西，那个合作伙伴卖给我们东西，这个那个的有什么区别？买卖的区别是在商务合同里面，是在帐户的进出帐务上；
3. 最好不要区分(站在老板的角度)；尽量将货物卖给每个可能买的人，尽量建立更多的采购渠道降低成本。
[解决办法]
uup
[解决办法]
据说供应商和客户都属于“业务伙伴”， 在很多系统都是在一张表里
不过要是你做的不是通用的或者LZ不是在软件公司做的话，或者那家企业不多情况出现供应商和客户是同一家伙的情况下 那分开来比较安逸些
[解决办法]
分开分开
[解决办法]
个人觉得分开好，不然光编码都搞不定了
[解决办法]
如果数据量不大，建议合成一个表。然后用标识列区分筛选。这样数据库方便管理。
[解决办法]
分别建表。
毕竟有许多字段是不同的,就和[学生]与[老师]没人会想把这两个表和成一个
[解决办法]
3个表就OK了..
Company - Contact
/ \
Customer Supplier
[解决办法]
你这种需求，一个表没有问题，也很容易梳理。
[解决办法]
区分开好，这样开发和维护都有更大的伸缩性和可扩展性。
[解决办法]
1) 分开的意见占绝对多数
2) 理由主要是"是两个事物","容易编码","设计清晰"
3) 怎么做还要看楼主的需求。（个人依然保留观点，其实这是一种对事物的不同抽象法而已。如果要分表，贵公司未来业务做大了，是否要设如下表:客户、供应商、代理商、零售商、代理客户、...）
[解决办法]
建议：表合在一起，用视图区分
[解决办法]
我们的系统里是合在一起的。但是实际使用感觉还是分开方便。如果客户和供应商为同一人的情况不多，则分开好，即便这种情况多，还要看你们财务的要求，要求他们的往来账合并还是分开，一般财务是要求分开往来账的。但是合并一起方便控制销售信贷额度。
以一个正在使用合并在一起的用户的感受来说，我认为还是分开方便些。
[解决办法]
[netcup]:我们的系统里是合在一起的。但是实际使用感觉还是分开方便。如果客户和供应商为同一人的情况不多，则分开好，即便这种情况多，还要看你们财务的要求，要求他们的往来账合并还是分开，一般财务是要求分开往来账的。但是合并一起方便控制销售信贷额度。以一个正在使用合并在一起的用户的感受来说，我认为还是分开方便些。
[jxwangjm]:如果分开设计，那么在处理月结时，应付帐款和应收帐款似乎必须分开处理，必须有交易单据，这在实际上来讲，有些难以理解，不过好像合起来处理，也不是很好处理
----------------------------------------------
这是另一个问题了:关于财务的表设计。-- "客户"表和财务表是分离的。
首先"客户"表保存的是"客户的信息", 客户的账户信息另外建表，一个客户可以有多于一个的账户 (如果某"客户"有多重身份，可以将不同的账户id设置为不同类型，供不同的身份使用 -- 某"客户"的销售帐户和供应帐户..)。
财务表按照财务的收支两条线的原则分表：收入表，支出表；表里当然要保持帐户信息 (当然也可以在一张表里通过类型区别然后建视图分开。) -- 这是交易记录
[解决办法]
针对客户应用程序的复杂度.
[解决办法]
TIM_SpAC是不是北京时空的？我怎么越看越象？
[解决办法]
建议分开~
[解决办法]
哈哈。我是北京的,但我不是"北京时空"的。
time and space is anyway and anyware. :)
[解决办法]
呵呵。呵呵，o(∩_∩)o...
[解决办法]
看楼主的应用场合，比如CRM，我就建议不区分，因为很多情况下客户往往也可以是供应商。
而供应商也可以成为客户，统一在一个表有好处。
[解决办法]
我的意见:
强烈合并为一个表,在代码逻辑中一个boolean值或整型值就可将其区分,方便扩展,减少表维护数量,可乐而不为,简单事情简单做!
除此之外,我把:
1.库存帐/出纳帐/往来帐/总帐/明细帐,合成了一个表;
2.货品类别/账本/地区/工序类型/会计科目/部门,合成一个表;
这种方法在实践中我感到维护及扩展相当方便.特别是数据导入导出,加密,索引建立等因为表的数量少了而容易管理;
[解决办法]
还是说老话吧，需要找出自己的平衡点
不同人的平衡点是不同的，不同企业应用的平衡点也是不同的
