数据库设计疑问
本帖最后由 XYangUK 于 2012-11-08 21:15:12 编辑 我正在设计一个数据库用于处理客户，订单，发票，付款的关系
我目前把客户和订单进行了多对多连接，订单和发票进行了多对多连接

不过不太清楚付款应该如何处理？应该将“客户”和“发票” 与“付款” 连接起来吗？

大概就是

客户--订单-发票
  \                  |
   \                 |
    \                |
    付款--------|

请问这样对吗？有没有需要纠正的地方？
------最佳解决方案--------------------

引用:

引用:怎么都是多对多关系？

好吧，正确的应该是：

一个客户对应多个订单，多个订单对应一个发票，一个发票对应多个付款（系统要求支持部分付款功能）

这样对吗？

 
关系确定了 ，数据库的表也就出来了。
客户表，订单表 （存发票号),发票表，付款表（存发票号） 齐了吧
------其他解决方案--------------------
7楼：你那些主要是用于展示，如果不涉及运算，倒没所谓，而且不是非要达到什么范式才是好设计，但是连第一范式都不符合的话就没辙了。

6楼：部分付款是啥意思？解释一下，业务不熟

5楼：按照常规设计，一般多对多的时候会引入一个关系表。这样比较灵活，冗余也少。一对多的话，两个表就够了。
------其他解决方案--------------------
我个人给个小意见，客户，订单，发票这三个之间每个两两对应加个关系表。这样相对冗余会少一点，灵活性也会搞点，但是不是非必要。你自己衡量一下
------其他解决方案--------------------
怎么都是多对多关系？
------其他解决方案--------------------

引用:

怎么都是多对多关系？

好吧，正确的应该是：

一个客户对应多个订单，多个订单对应一个发票，一个发票对应多个付款（系统要求支持部分付款功能）

这样对吗？
------其他解决方案--------------------

引用:

引用:怎么都是多对多关系？

好吧，正确的应该是：

一个客户对应多个订单，多个订单对应一个发票，一个发票对应多个付款（系统要求支持部分付款功能）

这样对吗？

如果你的业务没错的话，用我2楼的方法可以解决。
------其他解决方案--------------------

引用:

我个人给个小意见，客户，订单，发票这三个之间每个两两对应加个关系表。这样相对冗余会少一点，灵活性也会搞点，但是不是非必要。你自己衡量一下

如果客户与订单采用一对多的关系呢？那就不用加中间表了吧？

一楼我的描述不是很对，我对数据库设计有点迷茫哈

这是我目前的结构，请指点一下付款表应该如何放？

------其他解决方案--------------------

引用:

引用:引用:怎么都是多对多关系？

好吧，正确的应该是：

一个客户对应多个订单，多个订单对应一个发票，一个发票对应多个付款（系统要求支持部分付款功能）

这样对吗？如果你的业务没错的话，用我2楼的方法可以解决。

好的，那么如何处理“部分付款”的功能呢？是不是等于建立一个付款的子表和付款的总表？
------其他解决方案--------------------
另外，如果要在客户的表中加入“送货地址”“送货邮编”“账单地址”“账单邮编”
是不是就算是违反了第三范式了？
------其他解决方案--------------------

引用:

另外，如果要在客户的表中加入“送货地址”“送货邮编”“账单地址”“账单邮编”
是不是就算是违反了第三范式了？

地址 单独出来一个表 ，别放客户里
------其他解决方案--------------------

引用:

引用:引用:怎么都是多对多关系？

好吧，正确的应该是：

一个客户对应多个订单，多个订单对应一个发票，一个发票对应多个付款（系统要求支持部分付款功能）

这样对吗？ 
关系确定了 ，数据库的表也就出来了。
客户表，订单表 （存发票号),发票表，付款表（存发票号） 齐了吧

差不多就是这样的。谢谢指点
还有个问题，如果我把他们都画在UML图里，是不是只要牵扯有外键的表，就一定要用线和那个外键所对应的另外的表的主键在Uml图里连接起来？

比如客户连订单，这个没问题。付款表里肯定会涉及到客户与操作的员工，是不是还要把付款表和客户，员工都在UML里连接起来？
------其他解决方案--------------------