如何高效存储多类别、多属性的数据？

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) 

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

仅我的两分钱，我希望它能有所帮助。

问候。

Answer 2

如果您的数据集合不太大，Entity-Attribute-Value< /strong> (EAV) 模型可能很适合这个要求。

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

这种格式非常实用，特别是因为它的灵活性：它允许逻辑模式中的后期和正在进行的更改（添加新类别、添加/更改给定类别的属性等）以及隐式数据 -在应用程序级别驱动处理底层目录的逻辑模式。这种格式的主要缺点是[在某种程度上]更加复杂、抽象、实现，并且主要是当目录大小增长时（例如超过一百万个实体的范围）在扩展等方面的一些限制。

请参阅 这个 SO 答案中详细描述的 EAV 模型我的。

Answer 3

受到这个问题和其他类似问题的触发，我写了一个 关于如何使用图形数据库处理此类情况的博客文章。简而言之，图形数据库不存在“如何将树/层次结构强制放入表中”的问题，因为根本不需要它：您按原样存储树结构。他们并不擅长所有事情（例如创建报告），但这是图形数据库的亮点。