Sql 数据库设计：在数据结构不是静态的情况下如何避免序列化

我最近遇到了设计数据库的需要。由于这是我第一次，我想我最好征求一些建议，以确保我的基础坚实

目标

我想将对象（POD结构最好被认为是多重贴图）存储在 用于存储和查询的SQL数据库。对象的内容及其“结构”不断被修改。将通过查询和更新集中访问数据库

用例

首先，每个对象都应该有一个唯一的标识符

第二，存在不同类型的对象。例如，ObjectA是ClassA的一个实例。ClassA可以具有属性A1、A2、A3等。因此，ObjectA可以（但不是必需的，允许NULL）具有这些属性的值。但是，这些属性中的每一个都可能有多个值，即：

ObjectA.A1=“foo”

和

ObjectA.A1=“bar”

。ClassA的属性数量可以更改。为了简单起见，只能添加属性，不能删除属性

第三，属性不是特定于一个类的，即：类B的对象也可以具有属性A1、A2等。因此

ObjectB.A1=“foo”

也是可能的。我不确定这是否会改变什么，但我有一种感觉，在设计中，每个属性都对应一个表

最后，必须支持以下伪查询和操作：

• 获取属性A1等于“bar”的ClassA类型的所有对象
• 获取ObjectB的所有属性
• 向ClassA类型的对象添加属性A4
• 添加一个ClassC类型的对象，该对象具有属性A1=“foobar”，A2=“bar”

限制

首先，我希望避免序列化数据，因此不可能在一列中包含多个值。数据库应该规范化，数据结构应该是原子的。数据库的查询将非常频繁，因此我不能浪费时间来实现复杂的查询机制。我最终会重新发明轮子（可能也是方形的）

其次，我不能使用对象内部结构的任何先验知识，因为这只能在运行时才可用。例如，在上面的用例中，属性是事先不知道的。因此，虽然我曾考虑过一种设计，其中每个属性都是一个表，但我不知道如何在这样的设置中获取对象的所有属性

环境

我使用SQLite 3.7，C++。 问题

满足所述问题要求的适当、灵活的数据库设计是什么

欢迎提供任何有用的见解或可靠设计的帮助、建议或提示

谢谢

---

ps：我对关系数据库只有基本的理论熟悉和有限的实践经验，当然之前没有任何专业经验。在过去的一周里，我一直在阅读这个主题，并掌握了一些我认为与我的案例相关的概念（规范化、外键等），但目前我仍在阅读我的书。

如果这是你第一次外出，并且你的项目看起来很重要，你可能想投入时间和精力从头开始学习基础知识。CJ Date和许多其他作者都有书籍和在线教程，可以带您了解基础知识。它们是优秀的作品

其中有一些领域几乎完全由专制统治。数据库设计并非如此。首先，大约42年前，EF Codd在一个非常坚实的数学基础上奠定了基础，随着时间的推移，基本模型一直保持良好。取得了进展，但几乎没有回溯。为了改变而很少改变

SQL在其漫长的生命周期中也同样具有很大的稳定性

其次，数据库设计中的反复试验可能会带来巨大的成本。在很多情况下，新手做出的不幸选择最终导致数百万的数据投资无法实现

---

试错有它的位置。小贴士和花招都有自己的位置。答案就这样有了自己的位置。但是正式学习也是如此。

如果你不知道对象的属性，你就不能为它设计一个规范化的关系数据库。需要能够在运行时定义新对象和新属性将是一件非常痛苦的事情。这可能是使用。然而，我会尝试首先确定更多的需求，因为它们有点难以处理。EAV模型是需要考虑的。您还可以使用元模型的复杂实例化，以及在某些商业产品（如企业元素）中发现的物理模型@Clockwork Muse-EAV模型似乎是我应该进一步研究的对象。谢谢