【问题标题】:Product catalogue storage in mongoDB from an RDBMS perspective从 RDBMS 角度看 mongoDB 中的产品目录存储
【发布时间】:2017-07-09 21:33:40
【问题描述】:

我有一个产品页面,其 URL 形式为 http://host/products/{id}/{seo-friendly-url},其中“seo-friendly-url”部分可能类似于 category/subcategory/product

products 控制器获取具有指定 ID 的产品,然后确保后面的 URL 对产品是正确的 - 如果不是,用户将被重定向到适当的 URL(商店中的所有 URL 都是正确生成的,重定向只是为了维护一个规范的 URL,以防用户输入错误或由于谷歌抓取它而导致 URL 发生变化等)。 ID 确保快速查找产品,最后部分确保关键字进入 URL。

为了检查 URL,我有一个 SQL 视图,它利用递归公用表表达式将产品 URL 块与其父类别 URL 的 URL 连接起来,一直到层次结构(通常只有 3 深)。

我最近遇到了面向文档的存储,我发现它在各种情况下都非常有用(例如,我的产品实体目前在不同的表中都有标签和多价购买价格和属性等)。

那么关于我的问题 - 我怎样才能在 mongoDB 中实现上述功能,或者有没有更好的方法来考虑它?天真的方法是单独检索层次结构中的每个类别,但我假设这会很慢。

相关:我在文档中读到跳过/限制对于大型结果集来说很慢 - 对于零售网站类别中可能出现的 25 种产品的最多 10 页来说,这是否会引起注意?

【问题讨论】:

    标签: sql mongodb nosql


    【解决方案1】:

    我认为您最好的选择是将完整的蛞蝓与产品一起存放。然后,当您获得产品时,只需检查 slug 是否匹配,如果不匹配,则重定向。现在,权衡是,如果你想重命名一个类别,你需要做一个批处理工作来查找该类别中的所有产品并更改它们的 slug。好消息是类别重命名将比视图少得多(希望如此),因此您的总负载将会减少。

    不知道skip和limit与这个问题有什么关系,除了它们都涉及mongodb。无论如何,对于 25 个结果,它真的没问题。限制并不慢,如果小于 100(默认的第一批大小),实际上可以加快速度。跳过可能会损害性能,但只能让它变得像您在没有额外网络流量的情况下获取所有跳过的文档一样慢。因此,我不会跳过 100 万个文档,但跳过 100 个就可以了。

    【讨论】:

    • 谢谢。我曾认为批量重命名是一个缺点,但你是对的 - 它相对不常见,所以不那么重要。跳过/限制模糊相关,因为它涉及产品和从 SQL 到面向文档的转换,但我下次会发布单独的问题,对不起! :)
    【解决方案2】:

    您可以为名为@9​​87654321@ 的集合建模,文档如下:

    product:{id:someId,category:someCategory,subcategory:someSubCategory,productSlug:somenameslug}
    

    在给定 id、类别和子类别的情况下获取产品的查询类似于:

    db.products.find({id:123,category:cat,subCategory:subcat})
    

    这听起来很简单,但鉴于我对您的问题 IMO 的理解,这应该是一个好的开始。

    对于您的其他问题,有 skiplimit 修饰符来帮助分页。

    【讨论】:

    • 谢谢,但我想你可能误解了我的问题。我正在寻找一种方法来从父类别 slug 和产品 slug 的组合中生成产品 URL。我关于跳过和限制的问题也是关于性能的。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-04-24
    • 1970-01-01
    • 2016-03-26
    • 1970-01-01
    • 2012-03-22
    相关资源
    最近更新 更多