电子商务店面网站:以编程方式发现类似产品

Question

我正在开发一个店面Web应用程序.当潜在客户在网站上查看产品时,我想自动从数据库中建议一组类似的产品(与要求人员明确输入产品相似性数据/映射相比).

实际上,当您考虑它时,大多数店面数据库已经有很多可用的相似性数据.在我的情况下Products可能是:

• 映射到Manufacturer(又名Brand),
• 映射到一个或多个Categories,和
• 映射到一个或多个Tags(aka Keywords).

通过计算产品与所有其他产品之间共享属性的数量,您可以计算"SimilarityScore",以便将其他产品与客户正在查看的产品进行比较.这是我最初的原型实现:

;WITH ProductsRelatedByTags (ProductId, NumberOfRelations)
AS
(
    SELECT  t2.ProductId, COUNT(t2.TagId)
    FROM    ProductTagMappings AS t1 INNER JOIN
                ProductTagMappings AS t2 ON t1.TagId = t2.TagId AND t2.ProductId != t1.ProductId
    WHERE   t1.ProductId = '22D6059C-D981-4A97-8F7B-A25A0138B3F4'
    GROUP BY t2.ProductId
), ProductsRelatedByCategories (ProductId, NumberOfRelations)
AS
(
    SELECT  t2.ProductId, COUNT(t2.CategoryId)
    FROM    ProductCategoryMappings AS t1 INNER JOIN
                ProductCategoryMappings AS t2 ON t1.CategoryId = t2.CategoryId AND t2.ProductId != t1.ProductId
    WHERE   t1.ProductId = '22D6059C-D981-4A97-8F7B-A25A0138B3F4'
    GROUP BY t2.ProductId
)
SELECT  prbt.ProductId AS ProductId
        ,IsNull(prbt.NumberOfRelations, 0) AS TagsInCommon
        ,IsNull(prbc.NumberOfRelations, 0) AS CategoriesInCommon
        ,CASE WHEN SimilarProduct.ManufacturerId = SourceProduct.ManufacturerId THEN 1 ELSE 0 END as SameManufacturer
        ,CASE WHEN SimilarProduct.ManufacturerId = SourceProduct.ManufacturerId 
            THEN IsNull(prbt.NumberOfRelations, 0) + IsNull(prbc.NumberOfRelations, 0) + 1
            ELSE IsNull(prbt.NumberOfRelations, 0) + IsNull(prbc.NumberOfRelations, 0)
        END as SimilarityScore
FROM    Products AS SourceProduct, 
        Products AS SimilarProduct INNER JOIN
        ProductsRelatedByTags prbt ON prbt.ProductId = SimilarProduct.Id FULL OUTER JOIN
        ProductsRelatedByCategories prbc ON prbt.ProductId = prbc.ProductId
WHERE SourceProduct.Id = '22D6059C-D981-4A97-8F7B-A25A0138B3F4'

这导致如下数据:

ProductId                            TagsInCommon CategoriesInCommon SameManufacturer SimilarityScore
------------------------------------ ------------ ------------------ ---------------- ---------------
6416C19D-BA4F-4AE6-AB75-A25A0138B3A5 1            0                  0                1
77B2ECC0-E2EB-4C1B-A1E1-A25A0138BA19 1            0                  0                1
2D83276E-40CC-44D0-9DDF-A25A0138BE14 2            1                  1                4
E036BFE0-BBB5-450C-858C-A25A0138C21C 3            0                  0                3

我不是SQL性能大师,所以我有以下问题为您提供SQL大师:

• 是共同的表表达式 S(CTE的)适当/最佳在这种使用情况下？(他们确实似乎更容易阅读/遵循SQL).鉴于上面提到的模型,有没有办法在任何地方保存连接？

和

• 这是否是索引视图(持久性)的良好候选者,还是会增加源数据更改的成本？在这种情况下,我将使这个存储过程更新SimilarProductMappings任何给定产品的物理表.

Answer 1

你问了很多问题。我将尝试逐一阐述，但不会涉及太多细节。

1. CTE 与派生表是语法糖。它在性能方面没有区别。使用它们的唯一好处是您可以重用它们，而不是再次复制/粘贴/键入派生表。但是，在这种情况下您不会重用它们，因此这取决于您。

2. 索引视图：请记住，视图上的索引就像表上的索引一样，几乎没有例外。想象一下，就像为您的特定查询/视图创建另一个表并将其存储在磁盘上以便更快地检索。当底层数据发生变化时，这些索引就必须更新。是的，这会产生巨大的资源影响。一般来说，我宁愿看到有人编写一个使用基表上的索引的查询，如果他们需要更多索引来实现特定目的，那么请详细查看它，而不是全面查看具有多个表的视图。这更容易维护，也更容易弄清楚为什么你的 CRUD 花费的时间比预期的要长。索引视图不一定有问题。但是，在像这样的应用程序数据库模型上添加它时要非常小心，因为更新/插入/删除的表很复杂。索引视图最适合的用途是在报告数据仓库中。无论如何，在不了解视图对表的 CRUD（创建、读取、更新、删除）操作的作用之前，不要在视图上放置索引。在 CRM 或应用程序支持类型的数据库中，我在很大程度上会远离它们，除非存在静态需求并且它不会真正影响性能。

阅读本文：http://technet.microsoft.com/en-us/library/ms187864 (v=sql.105).aspx

请注意，页面下方的 3/4 部分讨论了不应使用它的情况，我认为您的情况适合 4 / 5 的不应使用它的场景。

1. 关于保存连接...请记住，完整外部连接是最影响效率的因素之一。在我看来，你拥有它的唯一原因是因为你没有将制造商包括在你的 CTE 中。您可以将其包含在 CTE 中，然后在最终查询中按 cat/tag 聚合匹配数，将其组合在一起即可获得分数。这样，您只有两个左外连接（每个 CTE 一个），然后将两个计数相加并按相同制造商（案例声明）、productId 等进行分组。

2. 最后......我会考虑将所有这些放入非标准化表中，甚至可能放在预先计算的立方体中。让我们考虑一下有关您的要求的几件事：产品的相关性分数是否需要实时存在？如果是，为什么？当添加/删除新产品时，这不是关键任务。任何说它需要直播的人可能并不是真正的意思。b. 检索速度。我可以使用临时表重写您的查询，确保索引正确等，并在存储过程中提出相当快的查询。但是，我仍在聚合数据库中的数据，以便在每次页面加载时显示在我的店面中。如果数据被预先计算并存储在每个产品的productId和分数的单独表中，并通过productId进行索引，则检索将非常快。您可以每晚、每小时等方式在 ETL 中对表进行中继和重新加载，而不必担心维护每次重建的索引。当然，如果您的店面是 24/7/365，您需要编写一些数据库端代码来担心版本控制，以便您的应用程序永远不必等待数据库正在重新计算。

另外，如果没有其他情况，请确保至少在 Web/应用程序服务器上缓存此信息。有一点是肯定的，如果您采用上面的解决方案，那么您需要在您的网站中构建一些内容，这样它就不会等待数据返回并缓存它。

希望一切有帮助。