数据库设计：当数据结构不是静态时如何避免序列化答案

【问题标题】：Database design: how to avoid serialization when data structure is not static数据库设计：当数据结构不是静态时如何避免序列化
【发布时间】：2012-11-23 12:13:16
【问题描述】：

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

目标

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

用例

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

其次，存在不同类型的对象。例如，ObjectA 是 ClassA 的一个实例。 ClassA 可以具有属性 A1、A2、A3 等。因此，ObjectA 可以（但不是必需的，允许 NULL）具有这些属性的值。但是，这些属性中的每一个都可能有多个值，即：ObjectA.A1="foo" 和ObjectA.A1="bar" 都是可能的。 ClassA 的属性数量可以改变。为简单起见，属性只能添加，不能删除。

第三，属性并不特定于一个类，即：ClassB的对象也可以具有属性A1、A2等。因此ObjectB.A1="foo"也是可能的。我不确定这是否会改变任何东西，但我感觉它可能在每个属性对应一个表的设计中。

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

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

限制

首先，我想避免序列化数据，因此单列中的多个值是不可能的。数据库应该被规范化，数据结构应该是原子的。数据库会被非常频繁地查询，所以我不能浪费时间尝试实现复杂的查询机制。我最终会重新发明轮子（也可能是方形的）。

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

环境

我使用的是 SQLite 3.7，C++。

问题

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

非常欢迎任何有助于获得有用见解或可靠设计的帮助、指示或提示。

谢谢！

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

【问题讨论】：

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

标签： sql database sqlite database-design

【解决方案1】：

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

IT 中的某些领域几乎完全是临时性的。不是这样的数据库设计。首先，EF Codd 在大约 42 年前奠定了非常坚实的数学基础，并且随着时间的推移，基本模型一直保持得很好。有进步，但几乎没有倒退。为了改变而改变很少。

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

接下来，数据库设计中的反复试验可能会付出巨大的代价。有几十个案例表明，新手做出的不幸选择最终导致数百万的数据投资损失惨重，但没有成功。

尝试和错误有它的位置。技巧和窍门各有千秋。 SO上的答案有它们的位置。但正式学习也是如此。

【讨论】：