Question

我有一个包含ProdID列的表格，后面跟着一组分类法和术语。对于一个简单的例子：

ProdID  |  Type  |  Size  |  Color  |  Flavor  |  ...
10231   |  A     |  LG    |  GREY   |  BAD     |  ...

总共有73个术语分为12个分类法。

该表有大约43,000个条目。

用户会显示一个分类过滤器，可以选择要显示的各种分类和术语组合（类似于亚马逊或Zappos上的搜索结果）。

客户希望在列表中的每个字词旁边都有一个产品计数，如果他们将该字词添加到当前选择中，则会显示他们将收到多少结果。

当您开始浏览产品时，这与zappos上看到的功能相同。如果单击它，您将在每个“类别”旁边显示一个计数，即您将看到的结果数。（例如http://www.zappos.com/womens-casual-shoes~94 - 在“类别”的侧边栏部分，每个字词旁边都有一个计数）

我看到它的方式，计算潜在结果的数量似乎是计算得到这些结果的大致相同的问题，因此在每个页面加载上运行73个复杂的SQL查询似乎是一个糟糕的（也就是缓慢的）选择。

或者，预先计算每个可能的过滤器选择的计数或结果似乎是一个傻瓜差事（如果我的数学是正确的，有2 ^ 73个可能的不同子集，如果每个查询需要1ms运行，则需要3年11年完成）

因此，我假设有一个更好的数据结构来计算，或者结果是在运行中计算，并且每个请求都被缓存，因此常见请求运行得更快。

是否有更好的数据结构，可以更快地产生这些计数？

Answer 1

您的原始表格为T，您可以创建并取消忽略表格U。

ProdID  |  Filter  |  Value 
10231   |  Type    |  A
10231   |  Size    |  LG
10231   |  Color   |  Gray
10231   |  Flavor  |  Bad

然后计算每个分类总计

SELECT Filter, Value, Count(*)
FROM U
WHERE U.ProdID IN (SELECT T.ProdID
                   FROM T
                   WHERE color = @color  -- need build this filter dinamic.
                  )

Answer 2

我猜他们在内存中做了很多这样的事情，甚至可能没有SQL解决方案。亚马逊使用各种解决方案来满足他们需要处理的数据和吞吐量的大小，甚至开始使用他们的亚马逊网络服务来营销他们的一些技术。

也就是说，对于SQL解决方案......假设用户已选择颜色“黄色”，您应该可以为每个分类法执行以下操作。

SELECT
    type, COUNT(*) AS cnt
FROM
    Products
WHERE
    color = 'YELLOW'

然后你必须运行12次才能填写你的侧边栏。选择其他过滤条件后，您可以适当调整WHERE条款。

您还可以等到用户选择了一些最小搜索条件，将所有内容放入内存，然后根据用户选择并取消选择不同条件来计算您的计数。根据您拥有的产品数量和网站看到的流量，这可能会更快。

如何显示类别组合的计数？

2 个答案: