【问题标题】:Suggestion on database design - multiple tables involved into a relation关于数据库设计的建议 - 多个表涉及到一个关系
【发布时间】:2011-04-02 17:47:43
【问题描述】:

我的应用程序需要在多个表之间实现一对一的关系。我有一张存储公司的桌子(可以是客户和供应商,或两者兼而有之)。有两个位字段,客户和供应商。

然后我有不同的表用于各种操作:发票、银行操作、Cashdesk 操作。我需要将付款与发票配对。付款不是发票的确切金额,但可以拆分为每个发票数量。此外,一张发票可以拆分为多笔付款。付款可以来自银行或收银台操作

我最初的方法是创建一个表 PaymentRelations,其中包含外键 InvoiceID、BankOpID、CashOpID 和 Amount,对于它们之间的任何付款,我创建一个仅填写两个外键 ID 和相应金额的记录。通过这种方式,我可以随时知道每次操作(发票或付款)的支付金额。

还有RI要求,所以如果一个单据涉及到支付关系,是不能删除的(或者是级联删除,所以如果一个支付发票单据被删除,相关的PaymentRelations记录也会被删除,所以对应的操作被释放——它们不再参与支付关系,因此它们的金额可以完全用于其他支付关系)。

但是出现了另一种情况。由于合作伙伴既可以是客户也可以是供应商,因此可以在同一合作伙伴的客户和供应商端进行相同类型的操作之间进行补偿(例如,合作伙伴既是客户又是供应商,他作为供应商开具了 100 的发票并收到了发票作为 150 美元的客户,在收到和发送的发票之间补偿了 50 美元,其余的每张通过一个或多个付款操作支付)。 其他操作也可能发生这种情况(例如,他通过银行操作 100 付款,通过另一家银行操作 200 收款,这两个操作之间需要补偿 50;同样适用于 caskdesk 操作)。

你会用什么方法来模拟这种关系?

【问题讨论】:

    标签: sql-server database-design model


    【解决方案1】:

    我会购买会计软件而不是编写它。有些轮子值得重新发明;这不是其中之一。

    但如果必须的话。 . .

    位域是识别客户和供应商的错误方法。 This SO answer 应该可以帮助您解决与客户和供应商的问题。

    如果我必须设计一个会计系统,我想我会从电子表格开始。我会在该电子表格中设计一个交易表,这样我就可以了解某些交易的相似之处以及其他交易的不同之处。在这个阶段,我不会担心 NULL、重复组、传递依赖或其他类似的事情。

    在电子表格中开发了一个工作(ish)模型,然后我会尝试将其标准化为 5NF。

    【讨论】:

    • 谢谢,但这不是一个选择。该系统正在开发中,它解决了客户的一些特定要求,他们找不到其他的,他想要一个定制的系统
    • @bzamfir:更新了答案。
    猜你喜欢
    • 2018-01-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-08-23
    • 1970-01-01
    • 2019-04-01
    • 1970-01-01
    相关资源
    最近更新 更多