这是唯一真正的关系设计：

CREATE TABLE Objects (
  object_id INT AUTO_INCREMENT PRIMARY KEY,
  parent_object_id INT,
  -- also attribute columns common to all object types
  FOREIGN KEY (parent_object_id) REFRENCES Objects (object_id)
);

CREATE TABLE RedObjects (
  object_id INT PRIMARY KEY,
  -- attribute columns for red objects
  FOREIGN KEY (object_id) REFRENCES Objects (object_id)
);

CREATE TABLE BlueObjects (
  object_id INT PRIMARY KEY,
  -- attribute columns for blue objects
  FOREIGN KEY (object_id) REFRENCES Objects (object_id)
);

CREATE TABLE YellowObjects (
  object_id INT PRIMARY KEY,
  -- attribute columns for yellow objects
  FOREIGN KEY (object_id) REFRENCES Objects (object_id)
);

但是MySQL不支持递归查询，因此如果您需要执行复杂的查询来获取整个树，例如，您需要使用另一种方法来存储关系。我建议采用闭幕表设计：

CREATE TABLE Paths (
  ancestor_id INT,
  descendant_id INT,
  length INT DEFAULT 0,
  PRIMARY KEY (ancestor_id, descendant_id),
  FOREIGN KEY (ancestor_id) REFRENCES Objects (object_id),
  FOREIGN KEY (descendant_id) REFRENCES Objects (object_id)
  -- this may need additional indexes to support different queries
);

我在这里描述更多关于闭包表的信息：

• 我的答案是什么是将平面表解析为树的最有效/最优雅的方法？
• 我的演示文稿
• 我的书是。

是的，你可以很好地使用EAV设计。它适用于我们创建的应用程序，尽管经过大约3年的改进。您还可以使用通用表结构，并对一组对象使用任何特定的表。或者只为每个对象创建一个通用表。哪个表的对象是元数据存储库的一部分。如果您使用val_int、val_string类型的结构，那么除了存储值的位置之外，您将拥有Null列。您可以考虑使用MS SQL的稀疏矩阵功能。如今，磁盘大小有些便宜。因此，与传统结构相比，唯一的缺点是NxR行（比如对象的R属性），而不是N行。
除此之外，很少需要注意的是对象示例GUID、动态sql生成。。。