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
This package is not auto-updated.
Last update: 2024-09-29 05:41:58 UTC
README
## EAV 搜索 ## 当前版本 V0.1 当前版本还是开发版本,目前还没有加入“属性维护”“map-reduce”“属性版本”等特性,会在后续的开发中添加。目前只能依赖mysql进行处理,后续会完善Query进而兼容其他关系型数据库。
## 编写的目的
有一天,产品经理问我。他需要做一个功能,这个功能有一些实体,每个实体都属于一个类型,具有许多相似的地方,但大多数都是不相似的,特别是属性。光是查询相关的属性就有三十多项。
面对这样的情况,略加思索后我认为传统的关系型数据库的使用方式实际上已经无法满足需求,SQL当然是可以写出来的,但是这样的SQL是无法维护的。产品经理这个时候补充道。他需要能够根据市场变化新增产品类型以及属性以及属性的查询。
然后我确定行式的处理方式是无法满足需求的。是决定采用一个比较经典的反模式来处理这个问题。EAV。
## 适用的场景 同类型产品动态添加,细分产品属性众多,且有查询要求。 ## 如何使用 当前版本只能有效的存储一个search_id,通过Id将EAV search和用户的行式数据库关联上。 ## 拆分为列式的优势 列式存储对属性有无不敏感,并且可以较为容易的进行横向分表(至少比起行式的)。列式存储对将程序改为Map-Reduce的执行方式也是较为容易的。## 拆分为列式的劣势 并不是所有情况都适合列式数据库存储,这是一个SQL反模式,副作用也是有的,比如外键,数据库类型检测是无法使用的,数据的正确需要应用程序来保证。## 使用 待完成