Question

我需要开发一个应用程序，其中将有4种类型的用户实体（管理员，合作伙伴，公司和客户端），每个用户类型都有自己的一组详细信息，他们都应该能够执行常见操作，如发送消息，付款等。这些操作应该保存在一个表中，但它们需要引用确切的用户，尽管它是类型。

哪种数据库设计更合适？

Answer 1

我认为这是inheritance的完美案例。将公共属性放在一个表中并继承该属性以为不同的用户类型添加自定义属性。

混沌答案对我来说似乎有些混乱，如果你事先不知道你需要存储的属性是什么，那么它会很有用。

Answer 2

在“企业应用程序架构模式”中查看三种方法：

http://martinfowler.com/eaaCatalog/singleTableInheritance.html

http://martinfowler.com/eaaCatalog/classTableInheritance.html

http://martinfowler.com/eaaCatalog/concreteTableInheritance.html

选择取决于4种类型的用户实体将共享多少属性，以及系统将需要的用例。

Answer 3

“我只想再添加一个东西，你建议每个用户类型都有一个表格...我更喜欢这种方法但是我如何设计一个架构，我可以说用户ID 7（管理员）发送用户ID 537（客户端）的消息？或用户ID 70（公司）收到付款？“

没有什么可以阻止你这样做。有一个表{sender recipient message（-id）}，主键包含所有三个属性和两个FK {sender}和{recipient}。 FK指的是包含所有用户的COMMON属性的表的主键。

现在，您的下一个问题可能是，“但我想要一条规则，即X型用户不能直接向任何Y型用户发送消息”。

这就是（所谓的）关系DBMS的任何当前 IMPLEMENTATION 显示其弱点的点。即使是Oracle或DB2也无法以声明的方式执行。对于我来说，对于这个主题的评论非常适合我。

顺便说一下，尽管有所有的支持，你似乎对我的回应感兴趣。真的很感激。

Answer 4

user
================
id
user_type_id
name
etc

user_type
================
id
name (admin, partner...)
etc

user_detail
================
id
user_id
user_detail_type_id
value

user_detail_type
================
id
name

user_type_to_user_detail_type
================
id
user_type_id
user_detail_type_id
(maps which user types have which detail types)

数据库设计适用于多种类型的实体

4 个答案: