您已经重新发明了一个名为Entity-Attribute-Value的数据库设计。这种设计有很多缺点，包括您已经发现的缺点：很难以常规格式来复制查询结果，每个属性只有一列。
这是您必须执行的操作的一个示例：
SELECt c.id, c.date_created, c1.value AS name, c2.value AS email, c3.value AS phone, c4.value AS fax, c5.value AS websiteFROM contact_profiles c LEFT OUTER JOIN contact_attributes c1 ON (c.id = c1.profile AND c1.type = 'name') LEFT OUTER JOIN contact_attributes c1 ON (c.id = c1.profile AND c1.type = 'email') LEFT OUTER JOIN contact_attributes c1 ON (c.id = c1.profile AND c1.type = 'phone') LEFT OUTER JOIN contact_attributes c1 ON (c.id = c1.profile AND c1.type = 'fax') LEFT OUTER JOIN contact_attributes c1 ON (c.id = c1.profile AND c1.type = 'website');
您必须
LEFT OUTER JOIN为每个属性添加另一个。您在编写查询时必须知道属性。您必须使用
LEFT OUTER JOIN而不是，
INNERJOIN因为没有办法使属性成为强制性的（等同于简单地声明一列
NOT NULL）。
检索存储的属性，然后编写应用程序代码以遍历结果集，为每个属性创建一个对象或关联数组的效率要高得多。您无需以这种方式知道所有属性，也不必执行
n-way连接。
SELECt * FROM contact_profiles c LEFT OUTER JOIN contact_attributes ca ON (c.id = ca.profile);
您在评论中问，如果不使用EAV设计，如果需要这种灵活性，该怎么办？如果您确实需要无限的元数据灵活性，则SQL不是正确的解决方案。以下是一些替代方案：
- 存储一个
TEXT
BLOB，其中包含以XML或YAML格式构造的所有属性。 - 使用Sesame之类的语义数据建模解决方案，其中任何实体都可以具有动态属性。
- 放弃数据库并使用平面文件。
EAV和任何其他替代解决方案都需要大量工作。如果您确实需要数据模型中的这种灵活性，则应该仔细考虑，因为如果您可以将元数据结构视为相对不变的话，这要简单得多。
