以下数据库设计最糟糕的情况是什么?马上还是将来*
我正在编写我的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。
data_type是数据类型的唯一标识符。比如说,博客文章。primary_key是主标识的密钥(位于树的顶部)。属性与主标识相关,并通过primary_key附加到标识。
作为一个模块开发人员如何使用它的例子,有一个粗糙而简单的例子——使用PHP:
定义一个数组来表达数据模型,并将其映射到编码器可读字段:
$var['models']['module名称']['blog_post']=阵列('maintable'=>数组('
'primary_key' => 'post_id', 'blog_post' => 'data_type', 'title' => 'field1' '), 'attribute_table1' => array( 'attribute_key1' => 'category_id', 'primary_key' => 'post_id', 'field1' => 'tag' ),
);
据此,模块dev定义了一个"blog_post"数据模型,该模型由post-id、title和附加的标签组成,横跨两个表。属于模块"module_name"。
从那时起,如果我们说module_name是博客,那么开发人员访问这个数据对象需要做的事情应该是:
$data_access->get_data('blog','blog_post',post_id);
(模块名称、型号名称、数据id)
我建议使用EAV的混合方法——将公共字段放入每个实体的表中,然后对不常见的字段使用EAV。
这种方法的主要缺点是数据本身不是自记录的——你不知道它意味着什么。在未来,这意味着您必须将所有元数据信息开发为附加表,最终您将得到一个只有您才能理解的应用程序。对于常规关系表,表和列名是描述性的。使用EAV方法,属性名称与值一起存储。
其他缺点:
- 不能通过实现索引来加快对特定元素的访问
- 属性的给定值可以在任何列中,因此很难获得"全局视图"
- 您没有使用关系数据库的功能
- 不能定义表之间的外键关系