海量异构数据的数据库存储设计

Question

下面是一些我已经想了很长时间的事情，而且还没有看到真正的(好的)解决方案。这是一个问题，我想象许多游戏有，我不能轻易地想到如何解决(好)。想法是受欢迎的，但由于这不是一个具体的问题，不要费心地要求更多的细节-只是捏造！(并解释你编的是什么)。

好的，很多游戏都有(库存)项目的概念，而且通常有数百种不同的项目，所有的数据结构都是非常不同的--有些项目非常简单(“一块石头”)，还有一些项目背后可能有疯狂的复杂性或数据(“一本书”，“一个编程的计算机芯片”，“一个有更多项目的容器”)等等。

现在，这样的编程很容易--只要让所有的东西都实现一个接口，或者扩展一个抽象的根项。由于编程世界中的对象不需要在内部和外部看起来相同，所以对于任何类型的项目都有多少个私有字段和什么类型的私有字段没有问题。

但是，当涉及到数据库序列化(二进制序列化当然没有问题)时，您将面临一个难题:您将如何在一个典型的SQL数据库中表示这个问题？

我曾见过一些解决办法的尝试，但我没有一次感到满意：

1. 项的二进制序列化，数据库只保存一个ID和一个blob。

- Pro's: takes like 10 seconds to implement.
- Con's: Basically sacrifices every database feature, hard to maintain, near impossible to refactor.

​

1. 每个项目类型的表。

- Pro's: Clean, flexible.
- Con's: With a wide variety come hundreds of tables, and every search for an item has to query them all since SQL doesn't have the concept of table/type 'reference'.

​

1. 一个包含许多字段的表，这些字段不是每个项都使用的。

- Pro's: takes like 10 seconds to implement, still searchable.
- Con's: Waste of space, performance, confusing from the database to tell what fields are in use.

​

1. 有几个表有几个“基本配置文件”用于存储，在这些表中，相似的项被抛在一起，并对不同的数据使用相同的字段。

- Pro's: I've got nothing.
- Con's: Waste of space, performance, confusing from the database to tell what fields are in use.

​

你有什么想法？你有没有见过另一种效果更好或更差的设计？

Answer 1

这取决于您是否需要对这些属性进行排序、筛选、计数或分析。

如果你使用EAV，那么你会很好地自毁自己。尝试在EAV架构上做报告。

最好的选择是使用表继承：

PRODUCT
id pk
type
att1

PRODUCT_X
id pk fk PRODUCT
att2
att3

PRODUCT_Y
id pk fk PRODUCT
att4
att 5

对于不需要搜索/排序/分析的属性，请使用blob或xml

Answer 2

我有两种选择：

1. 一个表用于基类型，另一个表用于每个专门类型的“类”。 在此模式中，所有“对象”共有的属性存储在一个表中，因此您对游戏中的每个对象都有一个唯一的记录。对于书籍、容器、可用项等特殊类型，您可以为这些项目所需的每一组属性或关系提供另一个表。因此，每个特殊类型都将由两个记录表示:基对象记录和特定特殊类型表中的补充记录。 优点:您可以使用数据库的基于列的特性，如自定义域、检查和xml处理；在某些类型上可以使用更简单的触发器；查询在不同关注点上完全不同。 缺点:对于许多对象，您需要两个插入。
2. 对特殊类型的数据使用“类”枚举字段和类似于JSONB的字段。 这有点像您的#1或#3，除了一些数据库帮助。Postgres添加了JSONB，比旧的EAV模式有了改进。其他数据库具有类似的复杂字段类型。在此策略中，您将自己的迷你模式存放在JSONB字段中。kind字段声明了您希望在该JSONB字段中找到的内容。 优点:您可以在查询中提取特殊类型的数据；可以添加check约束并处理一个简单的模式；即使您的数据是异构的，也可以从索引中获益；查询和插入非常简单。 缺点:类似于JSONB的字段中的数据类型非常有限，您必须提交自己的验证。

Answer 3

是的，像这样设计数据库格式是件很痛苦的事。我正在设计一个通知系统，并且遇到了同样的问题。然而，我的通知系统并不像您的系统那么复杂--它保存的数据最多只有ids和用户名。我目前的解决方案是混合1和3-我序列化的数据是不同的每一个通知，并使用一个列的2个用户名(有些可能有2或1)。我回避方法2，因为我讨厌那个设计，但可能只有我一个人。

但是，如果您能够负担得起，我建议您在RDBMS领域之外思考--听起来，非RDBMS(特别是键/值存储)可能更适合存储这些数据，特别是如果项目1和项2与每个项目有很大的不同。