2013-03-20 16 views
1

我正在改写允许人们将钱从一个人转移到另一个人的应用程序。所以基本上有发件人和收件人。最初在表格中,我创建了发件人和收件人之间的一对多关系。如何为改变角色的对象设计表数据库

现在,有一个新的要求,即同一个发件人也可以是交易中的收件人,并且收件人也可以成为发件人(即收件人可以将钱退回给发件人)。这在我看来,现在没有单独发送者和收件人表的要点。

另一层困难是,如果我沿着这张单一表格的路线走下去,我该如何迎合发件人必须注册收件人的要求。对于发件人而言,我必须能够显示他/她的收件人是谁,即使该发件人尚未向他们汇款但只注册了他们。

回答

1

这应该让你开始。

  • 存在。
  • 发件人
  • 收件人
  • 发件人注册的收件人
  • 发件人TransactionTimeAmount收件人转移。

enter image description here

+0

这是怎么处理同一个人的多个accoutns? – 2013-03-20 13:07:11

+0

@PieterGeerkens它没有。它不是OP正在编写的应用程序的ERD;他只是陷入了发件人 - 收件人的角色。 – 2013-03-20 18:35:48

1

单个表的前提是荒谬的;一开始,你需要这些实体至少包括:

  • AccountOwner
  • 帐户
  • RegisteredSender
  • RegisteredRecipient
  • 交易

玩这种设置了一下,回调,遇到任何特定的困难。

+0

通过上述实体,当RegisteredSender向他/她自己转账时会发生什么情况。在这种情况下,RegisteredSender也是RegisteredRecipient。 RegisteredSender是否将其注册为RegisteredRecipients?然后,您还有另一种情况,即注册接收人发起转账,然后他们成为发件人,现在RegisteredSender将成为收件人。这个要求似乎有点牵强,但其真实性。 – Napoleon 2013-03-20 13:06:16

+0

这就是为什么Account是最低要求的实体之一;这样一个人就可以将资金从他们自己的一个账户转移到他们拥有的另一个账户。想想我列出的实体是如何相互关联的,然后寻找可能存在的任何漏洞。 – 2013-03-20 13:09:21

1

发送方不是一个发送者。发件人是个人(或更一般的法定方),可能扮演发件人或收件人或两者的角色

create table Party (
    id serial primary key, 
    name text not null 
); 

create table Payment (
    from_party_id int not null references party(id), 
    to_party_id int not null references party(id), 
    paid_at timestamp not null default current_timestamp, 
    check (from_party_id <> to_party_id) 
); 

create table Registered_Recipients (
    sender_id int not null references party(id), 
    recipient_id int not null references party(id), 
    check (sender_id <> recipient_id) 
); 
相关问题