sunyuw/eav_search

用于处理非常复杂条件的匹配

v0.1 2018-04-28 05:22 UTC

Requires

• php: >=7.2.0
• catfan/medoo: ^1.5
• league/climate: ^3.3
• ocramius/proxy-manager: ^2.2
• php-di/php-di: ^6.0
• rych/random: ^0.1.0
• vlucas/phpdotenv: ^2.4

Requires (Dev)

• php: >=7.2.0
• doctrine/orm: ^2.6
• league/climate: ^3.3

MIT

• sunyuw

README

#EAV search ##当前版本 V0.1 当前版本还是开发版本，目前还没有加上“属性维护”“map-reduce”“属性 版本”等特性，会在后续的开发中添加。 目前只能依赖mysql进行处理，后续会完善Query进而兼容其他关系型数据 库。

##编写的目的

有一天，产品经理问我。他需要做一个功能，这个功能有一些实体，每个实 体都是属于容一个类型， 具有不少相似的地方，但是大多数都是不相似的，特别是属性。光是查询相 关的属性就有三十多项。

面对这样的情况，略加思索后我认为传统的关系型数据库的使用方式，实际 上已经无法满足需求，SQL当然是可以写出来的，但是这样的SQL是无法维 护的。 产品经理这个时候补充道。他需要能够根据市场变化新增产品类型以及属性 以及属性的查询。

然后我确定行式的处理方式是无法满足需求的。是决定采用一个比较经典的 反模式来处理这个问题。EAV。

##适用的场景 同类型产品动态添加，细分产品属性众多，且有查询要求。 ##如何使用 当前版本只能有效的存储一个search_id，通过Id将EAV search和用户 的行式数据库关联上。 ##拆分为列式的优势 列式存储对属性有无不敏感，并且可以较为容易的进行横向分表（至少比起 行式的）。 列式存储对将程序改为Map-Reduce的执行方式也是较为容易的。 ##拆分为列式的劣势 并不是所有情况都适合列式数据库存储，这是一个SQL反模式，副作用也是 有的，比如外键，数据库类型检测是无法使用的，数据的正确需要应用程序 来保证。 ##使用 待完成