数据库设计。继承

想象一下，您正在开发一个Web应用程序，其中不同的“实体”（具有不同的属性）发送消息并与来自其他实体的公共消息进行交互。这些实体可能有几种类型：只是用户，私人公司，学院......数据库设计。继承

设计数据库我可以想到两个选项，我认为会工作，但我不知道哪一个更好，或者如果有是没有出现在我身上的其他更好的选择。

选项1：在不同的表中分隔不同的实体。在这种情况下，存储消息的表应至少有两列来标识发布它的实体，id和type。

选项2：使所有实体从父类继承。因此，存储消息的表只需要一个指向发布它的实体的ID的外键。这个选项看起来好多了，但问题是我找不到所有实体的通用属性，所以父表只会有一个id。

您认为哪个选项更好？有没有更好的选择？

PS：对于选项2，是否有必要让子表具有自己的id或将外键定义为主键就足够了？

谢谢。

来源

2016-07-24 DandyCC

我希望我能正确理解你的问题。
我们有几个实体，它们发布消息。我们正在努力寻找优化的设计解决方案来存储消息。

选项1：在不同的表中分隔不同的实体。在这种情况下，存储表信息应至少有两列，以确定发布它，ID的实体，并键入

有至少两列(id , type)，以确定发布者是不是一个很好的设计。由于我们试图用定制解决方案取代发行商的外键，副作用将失去数据完整性。考虑一下，如果没有现有发布商的ID，那么会阻止邮件被保存。或者当将要定义一些新的实体类型时。
正确的方法是让发布者拥有外键，并且最终会在消息表中包含多个可以为空的外键列。这不是赞赏，但更好的解决方案id+type。

选项2：使所有实体从父类继承。因此，存储消息的表只需要一个指向的外键给发布它的实体的ID。这个选项看起来好多了，但是问题在于我找不到所有的实体都有共同的属性，所以父表只会有一个id。

我会选择这种方法。

我无法找到共同属性的所有实体

消息发布的本质是最明显的共享功能（属性）。但我认为有，如姓名，注册日期，状态等共享的属性...

对于选项2，那会是必要的子表有其自己的ID或定义外键作为主键会在RDBMS足够

造型继承了一个解决方案：
父母的主键将子表和内的外键和本外键必须是子表的主键。

来源

2016-07-25 09:58:37

感谢您的回答。选项2对我来说似乎也更好 – DandyCC

随着NoSQL的到来，这些概念问题现在很容易解决。想象你有一个网络，就像你说的那样，你可以在其中保存任何类型的数据（一个与一个人，一组人或一个单一组织有关的网络信息），现在有一些解决方案。

我将给出一个关于NoSQL数据库文档如何解决这个问题的主要例子。您可以在一个集合/表格中解决所有消息。下面是一个例子：

[ 
    { 
     "message": "Test message", 
     "destination": [ 
      { "type": "user", "username": "user1" } 
     ] 
    }, 
    { 
     "message": "Test message", 
     "destination": [ 
      { "type": "org", "username": "company1" }, 
      { "type": "user", "username": "user3" }, 
     ] 
    }, 
]

当然，NoSQL数据库也可以像关系型数据库一样使用id。在前面的示例中，您可以在每条消息上以及每个目标对象列表中放置一个ID。

来源

2016-07-24 22:24:00 Odonno

谢谢，我不知道NoSQL有多强大，但我需要使用MySQL – DandyCC

好吧，我想你必须创建每种类型的目标所需的表和列的确切数目（1为用户，1为组织等）。不是一个灵活的解决方案，但它可以工作。 – Odonno

是的，这正是我必须做的。 – DandyCC

数据库设计。继承

回答

相关问题