如何有效地存储包含许多类别和许多属性的数据？

Question

我们在许多类别中拥有大量具有许多属性的数据，例如

category 1: Book

properties: BookID, BookName, BookType, BookAuthor, BookPrice

category 2: Fruit

properties: FruitID, FruitName, FruitShape, FruitColor, FruitPrice

我们有许多类别，如书籍和水果。显然，我们可以为它们创建许多表（例如MySQL），每个类别都可以创建一个表。但是这将需要创建太多的表，我们必须编写许多“适配器”来统一操作数据。

困难是：

1）每个类别都有不同的属性，这会产生不同的数据结构。

2）每个类别的属性可能随时都要更改。

3）如果每个类别一个表（太多表）

，则难以操纵数据

您如何存储此类数据？

Answer 1

您可以将数据库分为两部分：定义表和数据表。基本上，定义表用于解释存储实际数据的数据表（有些人会说，如果用XML表示定义表更优雅）。

以下是基本想法。

定义表：

TABLE class  
class_id (int)  
class_name (varchar)

TABLE class_property  
property_id (int)  
class_id (int)  
property_name (varchar)  
property_type (varchar)  

数据表：

TABLE object  
object_id (int)  
class_id (varchar)  

TABLE object_property  
property_id (int)  
property_value (varchar) 

最好还可以创建额外的层来解释结构，以便使数据层更容易对数据进行操作。当然，您必须考虑性能，易于查询等。

只是我的两分钱，我希望它可以提供任何帮助。

问候。

Answer 2

如果您的数据收集不是太大，Entity-Attribute-Value（EAV）模型可能很适合该帐单。

简而言之，此结构允许定义 类别 ，[必需或可选] 属性的列表（又名属性）此类别中的实体包括等，在一组称为 元数据 的表中，数据的逻辑架构，如果您愿意的话。实体实例存储在两个表中的头和值表中，其中每个属性存储在后一个表的一个[SQL]记录中（也称为“垂直”存储：以前是传统DBMS模型中的记录）值表的几个记录）。

这种格式非常实用，特别是因为它的灵活性：它允许逻辑模式中的后期和持续变化（添加新类别，添加/更改给定类别的属性等），以及在应用程序级别隐式数据驱动处理底层目录的逻辑架构。这种格式的主要缺点是[有些]更复杂，抽象，实现，主要是在目录大小增加时缩放等方面的一些限制，比如百万+实体范围。

请参阅this SO answer of mine中详细描述的EAV模型。

Answer 3

由这个问题和其他类似的问题引发，我写了blog post关于如何使用图形数据库处理这种情况。简而言之，图形数据库没有“如何将树/层次结构强制为表”的问题，因为根本不需要它：您按原样存储树结构。他们并不擅长一切（例如创建报告），但这是图数据库闪耀的情况。