1

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

category 1: Book

properties: BookID, BookName, BookType, BookAuthor, BookPrice

category 2: Fruit

properties: FruitID, FruitName, FruitShape, FruitColor, FruitPrice

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

困难在于：

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

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

3）如果每个类别一个表（太多表），很难操作数据

您如何存储此类数据？

4

3 回答 3

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)

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

只是我的两分钱，我希望它可以有所帮助。

问候。

于 2010-03-08T04:30:32.330 回答
1

如果您的数据收集不是太大，实体-属性-值(EAV) 模型可能非常适合。

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

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

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

于 2010-03-08T04:31:29.007 回答
0

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

于 2010-03-23T19:48:47.163 回答