因为商品(SKU)的属性不会变更的,所以这种规模很大的只读表的建立可以后台定期去做。做好后性能大大提高。类似地,你还可以做更多这种索引表。
甚至将一些查询的path缓存起来。

解决方案 »

  1.   

    有个比较愚昧,但也是聪明的办法,产品录入所有属性之后,对产品的所有属性做关联,并且将管理数据全部存储起来。
    比如录入了 华为D2 那么该手机有属性 华为 Android 1300w 5寸。那么在属性关系表就有数据 华为-华为D2  Android-华为D2 1300w-华为D2 5寸-华为D2
    华为+Android-华为D2, 华为+Android+1300w-华为D2 等等 …………这样在查询的时候,比如选到华为,那么从这个关系表就可以很快得到华为下Android的数量,1300w的数量。
    选到 1300w 5寸 就很快得到其他属性下的数量。
    如此楼主的问题似乎就解决了。
      

  2.   

    如果你只有关系数据库的思路,那么肯定要把脑筋想疼、想”死“的。你应该学学 NoSQL。
      

  3.   

    按我的理解,这些“手机”,“品牌”,“操作系统”,“屏幕尺寸”等都是事先做好的表格,淘宝上的用户发布商品的时候 按照这个表格选择的对应的属性,只能选择这些,不能选择表格定义之外的文字,最多给一个 “其他”  选项。然后当发现搜索词出现手机的时候就把手机这个预先设定好的表格展示出来。而且这些 “品牌”,“操作系统” 等有一个互相是否匹配的记录,比如选择IPHONE那么翻盖手机 肯定是不匹配的,就不显示了。然后根据选择的属性再去搜索。淘宝他们很多都是人工做的,并不能天马行空 匹配世间万物。
      

  4.   

    你先只考虑一种筛选的情况,查到所有关联商品ID集合,这个我相信你会。
    现在的情况仅仅是有多个这样的关联商品ID集合,你需要做的是HASH归并而已。
    这种东西必须依赖内存计算,定义合适的缓存数据结构对于单种筛选集合的定位至少可以做到log(n)的时间复杂度,真正消耗计算资源的是归并操作。
    如果你的内存足够大,你还可以缓存一定数量的最终结果。
      

  5.   

    NoSQL 怎么用,schema free么,可以任意存么。即使存了,不也得有个有效地方式检索出来么
      

  6.   


    属性之间应该有约束关系,但是有个问题就是,譬如说选800块钱的手机,就没有iphone,如果类似的约束多的话,这得定义多少约束啊? 另外,存储商品信息的数据格式应该如何建立,是按照帖子主人说的商品+商品属性+商品属性值来做么。我想的是,商品的种类繁多,是不是商品需要按照大分类进行切分建立不同的数据存储呢?
      

  7.   

    如果按照您说的,都是表格的,那手机商品一大堆表格,儿童玩具也一大堆表格。这是不是量也太大了。
    再说这种和之前说的商品属性和商品属性值应该是类似的吧。网上针对这种可选配置的都是通过后台录入的,
    baidu一大堆有类似的实现,但是实现这种动态效果的很少啊。还得看数据库表怎么设计了。
      

  8.   

    全文检索这些东西,还是交给 Lucene 去做比较合适,数据库只是一个存数据的地方。