【问题标题】:Design customer table in a relationship with tables Contact and Legal Entity在与表联系人和法人实体的关系中设计客户表
【发布时间】:2012-04-19 15:29:14
【问题描述】:

我有两个具有以下属性(字段)的表:

联系方式

  • IDContact
  • 姓氏
  • 名字
  • 父亲的名字
  • IDGender
  • 致意
  • 出生日期
  • ...

合法性

  • IDLegalEntity
  • 姓名
  • 法定名称
  • IDLegalForm
  • ...

我想在我的数据库中存储关于客户的信息。

客户

  • ID客户
  • 税号
  • IDTaxAuthority
  • ...

客户可以是自然人(联系人)或公司(法律实体)。 Customer 表应如何与 Contact 表和 Legal Entity 表相关联,以便在其他表中使用唯一的 CustomerID(主键)?

【问题讨论】:

    标签: database-design


    【解决方案1】:

    这通常是通过实现一个超类型表来完成的。通过在每个指向超类型的子类型表中放置一个外键来创建LegalEntityContact 子类型。你可以称它为PotentialCustomer

    然后将Customer 表中的外键添加到相应的超类型记录(在PotentialCustomer 中)。这使您可以将客户记录仅链接到一个表,从而避免多个可为空的外键。

    它还允许您拥有一个超类型的单个实例,而该实例恰好同时是多个子类型。这可能不适用于您的情况,但在您的法人实体在您的业务中扮演特定角色的情况下通常会出现这种情况。例如,很多时候您的供应商也可能是您的客户。

    【讨论】:

    【解决方案2】:

    我会改变很多事情。首先,摆脱那里的愚蠢的 ID 命名方案。以 ID 开头的一切看起来很奇怪。通常你会以 ID 结尾,而大多数 ORM 会寻找以 ID 结尾的约定。

    其次,我不会称您的自然人为“联系人”,除非他们碰巧是一家公司的联系人。否则,称他们为 Person。

    第三,两者都使用取决于你想怎么做。您想一视同仁地对待所有客户、人员和合法实体吗?如果是这种情况,您需要一个具有 UniqueID 的客户表。您使用相同的 id 作为您的 Person/Contact 表和 LegalEntity 的主键。这会创建客户到客户类型的 1:1 映射,并且它们共享一个通用 ID 系统。

    【讨论】:

      【解决方案3】:

      在客户表中创建列CustomerType(个人/法人实体),在法人实体和联系人(子)表中创建外键CustomerId来引用客户(父)表中的列CustomerId。

      【讨论】:

        猜你喜欢
        • 2015-07-26
        • 2013-02-05
        • 1970-01-01
        • 2014-07-15
        • 1970-01-01
        • 2022-01-09
        • 1970-01-01
        • 2014-11-30
        • 2011-05-16
        相关资源
        最近更新 更多