SQL Server上大型EAV /开放架构系统的性能

Question

有人在SQL Server中实现了一个非常大的EAV或开放架构样式数据库吗？我想知道这是否存在性能问题以及您如何克服这些障碍.

Answer 1

无论MS SQL Server与任何其他品牌的数据库相比,EAV最糟糕的性能问题是人们尝试进行怪物查询以在单行上重建实体. 这需要每个属性单独连接.

SELECT e.id, a1.attr_value as "cost", a2.attr_value as "color",
  a3.attr_value as "size", . . .
FROM entity e
  LEFT OUTER JOIN attrib a1 ON (e.entity_id = a1.entity_id AND a1.attr_name = 'cost')
  LEFT OUTER JOIN attrib a2 ON (e.entity_id = a2.entity_id AND a2.attr_name = 'color')
  LEFT OUTER JOIN attrib a2 ON (e.entity_id = a3.entity_id AND a3.attr_name = 'size')
  . . . additional joins for each attribute . . .

无论您使用何种数据库品牌,查询中的更多连接意味着几何上增加了性能成本.不可避免地,您需要足够的属性来超越任何SQL引擎的架构容量.

解决方案是以行而不是列来获取属性,并在应用程序代码中编写一个类来循环这些行,将值逐个分配到对象属性中.

SELECT e.id, a.attr_name, a.attr_value
FROM entity e JOIN attrib a USING (entity_id)
ORDER BY e.id;

这个SQL查询更简单,更高效,它可以弥补额外的应用程序代码.

我在EAV框架中寻找的是一些样板代码,它检索这样的多行结果集,并将属性映射到对象属性,然后返回填充对象的集合.

Answer 2

我不是 EAV 专家，但几位比我更有经验的开发人员评论说，Magento 的开源电子商务框架速度缓慢，主要是因为通过 MySQL 的 EAV 架构。最明显的缺点不容易克服。随着应用程序规模的增加，解决实体和属性值信息在何处以及如何表示的问题变得很困难。我听到的第二个反对 EAV 的论点是它需要低两位数的表连接，但有人评论说使用 InnoDB 而不是 MyISAM 提高了一些性能（或者反之亦然，但我完全不记得了） ）。