抽象实体的数据库设计答案

【问题标题】：Database design for an abstract entity抽象实体的数据库设计
【发布时间】：2018-09-05 20:40:35
【问题描述】：

我有一个名为Campaign 的抽象实体和一些最终实体，如FooCampaign、BarCampaign 等。这套是开放式的。所有最终实体都具有抽象实体中描述的公共字段。公共字段会随着时间的推移而变化，但不会经常发生变化——我可能想添加更多共享字段或删除其中一些。最终实体的字段也是如此。我想知道为此设计的数据库，这些是我正在考虑的选项：

关系型数据库，一个表用于公共字段，一个表用于每个最终实体，它们之间是一对一的关系。
关系型数据库，只有一个表，最终实体的任何唯一字段都保存在 JSON 列中。
NoSQL 数据库。

我的应用程序是用 PHP (Symfony 4) 编写的，所以我热衷于使用 Doctrine。我倾向于下意识地使用选项＃2，但真的不知道这些选项中的任何一个的利弊。我需要能够根据唯一字段查询活动，速度也很重要。

哪些选项更适合我的情况，还有其他选择吗？

更新

Doctrine inheritance mapping，在第一条评论中提到，似乎非常适合我的情况。但是，当没有像 Mongo 这样的用于无模式数据的 nosql 数据库时，为什么还要为此烦恼（尽管我的数据并不完全是无模式的）？所以问题是 RDBMS 与继承映射 VS NoSQL。

【问题讨论】：

您的用例似乎非常适合inheritance mapping。您仍然可以选择一张桌子或多张桌子。我过去通过单表映射解决了类似的问题（资产管理，其中资产可以是 PDF 或 JPEG 或 docx；共享某些数据，但每个数据也有唯一的数据），并且效果很好。然而，这可能取决于您的用例。
@k0pernikus Right 似乎非常合适。我现在只是对 RDBMS 与 NoSQL 有疑问。
最后，你不应该花太多时间来决定走哪条路。选择任何你觉得对你来说更舒服的解决方案。我认为这两种方法的所有缺点很可能不会影响你。 mysql 和 nosql 都足够好。我个人会偏向于单表继承。

标签： php database-design doctrine-orm orm nosql

【解决方案1】：

当广告系列出现时，我假设或预测会有很多要求来运行不同的查询来返回对您拥有的数据的分析。为此，您需要更大的灵活性和能力来访问可以运行分析查询的活动的每条小记录。如果您将不同的字段序列化在单个 json 列中，那么拥有 json 数据将大大限制您。

如果您想使用 MySQL，我的建议：

所以你有你提到的所有命令字段的活动表。对于动态字段，您可以有如下第二个表：

id  campaign_id field_name  field_value
1   1   area    somearea
2   1   budget  100
3   2   area    anotherarea
4   2   owner   someowner
5   2   is_prime    TRUE

因此，campaign_id 将是来自活动表的外键，field_name 和 field_value 是您更改的动态字段。这将使您可以灵活地为您的活动实体添加任意数量的动态字段，从而消除管理数据的烦恼。

我个人会喜欢使用像 Mongo 这样的 NoSQL，因为我不需要担心牢固的关系。我可以拥有尽可能多的灵活性来获取活动数据。更不用说，Mongo 有很好的聚合功能（MySQL 也有 :)）所以没有什么限制。最后是个人喜好。

【讨论】：

是的，我同意 NoSQL。如果我的数据模型的性质是这样的，我为什么要为关系数据库烦恼。只是没有太多的实践经验，这似乎有点过于复杂了。另一方面，我不喜欢在关系数据库中搞乱继承映射的想法。
我最初没有考虑继承映射。但我想您可以使用 RDBMS，只需检查系统中的数据（活动除外）是相关的还是完全由活动驱动（灵活）。 :)
对不起，我误会了，您说的是类似 EAV 的东西。查询会很慢，有很多连接。这是一个微服务，所以它是由活动驱动的。
它并不完全是 EAV，但它为您提供了灵活性，但代价是很少有大型查询。但是，如果使用适当的索引以正确的方式进行查询，即使数据非常大，这也不应该成为问题。但是越想，NoSQL 给我的选择的感觉就越强烈：)