【问题标题】:Entity Relationship Diagrma dilemma实体关系图困境
【发布时间】:2020-10-09 13:54:01
【问题描述】:

作为评估的一部分,我正在尝试为电子商务网站构建 E-R 图。 有一个客户和生产者作为电子商务网站的一部分作为玩家。 所以,我想到了创建一个表 - 以 LegalEntityID 作为主键和 customerUserID、producerID 作为外键的法人实体。其他属性将是 EntityType(个人或公司)、角色(客户、生产者)、姓名、地址、电话号码。 您认为这种设置的优点和缺点是什么?我可以想到个人v公司,然后维护CustomeruserID和PRoducerID创建另一个表作为Customer / Producer并使用主键作为CustomerUserID和ProducerID?这会让事情变得复杂吗?或者创建一个以角色 ID 作为主键的角色表,然后创建另一个表 - 以 LegalentityRole ID 作为主键的 LegalEntityrole,以角色 ID、LegalEntityID 作为外键。大家觉得呢?

【问题讨论】:

    标签: database-design data-modeling datamodel entity-relationship-model fpml


    【解决方案1】:

    这听起来像是一个可以充分利用继承结构的场景。

    我建议您使用包含必填字段的 Legal Entity 表,然后您的 CustomerProducer 表都继承自 LegalEntityId 作为外键的 strong>LegalEntity 表。通过这样做,您不需要拥有 Role 表。

    【讨论】:

    • 感谢 Nathan,我正在考虑使用 LegalEntity 表并避免使用 Customer / Producer 表,这样可以避免维护多个表。此外,属性是: 1. 客户用户 ID 2. 生产者 ID 3. 产品 ID 3. 产品外部 ID 4. 订单 ID 5. 订单日期 6. 客户姓名 7. 客户地址 8. 客户城市 9. 客户国家 10.生产者名称 11. 生产者地址 12. 生产者城市 13. 生产者国家 13. 单价 14. 数量单位 15. 总价 16. 总数量 17. 产品描述
    • 更多表并不总是坏事。只要确保您的 ERD 保持在第 3 范式,因为它是用于分配的。
    猜你喜欢
    • 1970-01-01
    • 2017-05-23
    • 2020-03-31
    • 2014-06-12
    • 1970-01-01
    相关资源
    最近更新 更多