Mysql 带有泛型字段的大型表可以替代EAV和关系表 下面的数据库设计最糟糕的情况是什么？现在还是将来*

我正在为我的micro MF编码，我正在考虑使用下面的数据库模式。将来所有模块都将使用它。我必须使用MySQL。我保留这些理由和解释，这样就不会有人在结束这个问题时说它是“基于意见的”，就像之前发生的那样。假设这就是我手上的问题，这就是我必须使用的解决方案。也就是说：

Main Table
-------------------

primary_key   data_type   field1   field2   field3   field4   field5   field6   field7 
-----------   ---------   ------   ------   ------   ------   ------   ------   ------ 

Attribute Table 1
-------------------

attribute_key1   primary_key   attribute_name   field1   field2   field3   field4   field5   field6   field7
--------------   -----------   --------------   ------   ------   ------   ------   ------   ------   ------

Attribute Table 2
-------------------

attribute_key2   primary_key   attribute_name   field1   field2   field3   field4   field5   field6   field7
--------------   -----------   --------------   ------   ------   ------   ------   ------   ------   ------

Attribute Table 3
-------------------

attribute_key3   primary_key   attribute_name   field1   field2   field3   field4   field5   field6   field7
--------------   -----------   --------------   ------   ------   ------   ------   ------   ------   ------

每个表的属性键可以相互引入

字段类型可以以任何适当的格式展开；也许有两个是长文的，一个是bigint，一个是tinyint，另一个是varchar

数据类型是数据类型的唯一标识符。比如说，博客帖子。primary_key是主标识的键（位于树的顶部）。属性与主标识相关，并通过主键附加到标识

作为模块开发人员将如何使用此功能的示例，使用一个粗糙而简单的示例-使用PHP：

• 定义表示数据模型并将其映射到编码器可读字段的数组：
  $var['models']['module\u name']['blog\u post']= 排列( 'maintable'=>数组（'
  ))

有了这个，模块开发人员定义了一个“blog_post”数据模型，它由post id、title和附加的标记组成，跨越两个表。属于模块“module_name”

从那时起，如果我们说模块的名称是blog，那么开发人员需要做什么来访问这个数据对象呢

$data\u access->get\u data（'blog'，'blog\u post'，post\u id）

---

（模块名称、模型名称、数据id）

我建议使用EAV的混合方法——将公共字段放入每个实体的表中，然后将EAV用于不常见字段

这种方法的主要缺点是数据本身不是自文档化的——您不知道它的含义。将来，这意味着您必须将所有元数据信息作为附加表进行开发，最终您将得到一个只有您才能理解的应用程序。对于常规关系表，表和列名是描述性的。使用EAV方法，属性名与值一起存储

其他不利因素：

• 无法实现索引以加快对特定元素的访问
• 属性的给定值可以位于任何列中，因此很难获得“总体视图”
• 您没有使用关系数据库的功能
• 不能在表之间定义外键关系

---

为什么不能为模块/插件创建新表？这只是在DAL中重新创建关系数据库，很糟糕。我不明白你为什么再次问这个问题。原因在问题本身中解释。解释是什么？我在这里看不到？这是第三段。我已经明确给出了原因有一个粗体的标题，所以现在不可能错过。问题是，每个实体的公共字段都不知道。它们可能是任何内容，这取决于开发人员正在编码的模块类型。出于自文档的考虑，所有数据模型都在模块初始化时加载到MF中，并且每个模块的数据模式类型都是已知的加载MF时。我打算在数据对象中提供方法来解决此类问题。我注意到我没有将属性类型字段添加到属性表中，尽管很抱歉-我应该这样做。你所说的没有错（我完全按照你的建议实现，因为它工作得很好）尽管我特别不同意关系数据库“强大”的相关性，但随着应用层越来越强大，关系数据库的强大程度一年比一年低。请参阅我对问题的评论。@Bohemian你到底实现了什么？我（几年前）实现了表示主要实体的事务数据库，但事务详细信息是EAV，因为事务的性质差异很大，并且不断添加新类型。使用EAV意味着在业务生命周期内不需要更改数据库。它发生了变化。此应用程序运行在哪种硬件上？使用什么样的内存、处理器能力。它是一个暴露于internet、可供最终用户使用的应用程序，还是仅由少量用户在intranet中使用。它能否处理具有多个条件的多个连接？

        'primary_key' => 'post_id',
        'blog_post' => 'data_type',
        'title' => 'field1'
  '),
  'attribute_table1' => array(

         'attribute_key1' => 'category_id',
         'primary_key' => 'post_id',
         'field1' => 'tag'

  ),