从RDBMS角度看mongoDB中的产品目录存储

我有一个产品页面，其格式为http://host/products/{id}/{seo-friendly-url}，其中“seo-friendly-url”部分可能类似于category/subcategory/product。从RDBMS角度看mongoDB中的产品目录存储

产品控制器获取具有指定ID的产品，然后确保随后的URL对于产品是正确的 - 如果不是该用户被重定向到适当的URL（店铺中的所有URL均正确生成不过，重定向只是为了保持一个规范的URL，以防用户迷惑或者因为Google抓取它而导致URL发生变化等）。该ID可确保快速查找产品，并且末尾的部分可确保关键字进入URL。

为了检查URL，我有一个SQL视图，它利用递归公用表表达式将整个产品URL块与其父类别URL的URL连接起来（通常只有3深）。

我最近遇到了面向文档的存储，我可以看到它在各种情况下非常有用（例如，我的产品实体具有标签和multibuy价格和属性等全部在不同的表中）。

因此，对于我的问题 - 我如何在mongoDB中实现上述功能，还是有更好的方法来思考它？天真的方法是单独检索层次结构中的每个类别，但我认为这会很慢。

相关：我已经在文档中看到skip/limit for对于大型结果集来说很慢 - 这对于每个可能出现在零售网站类别中的25个产品的10个页面的最大值是否会引起注意？

来源

2011-08-29 stewartml

我认为你最好的选择是将产品全部塞满。然后，当你得到产品时，只需检查是否匹配，如果不匹配，重定向。现在，权衡是如果你想重新命名一个类别，你将需要做一个批量工作来找到该类别中的所有产品并改变他们的slu gs。好消息是，类别重命名将比视图（希望）少得多，所以你的总负载将会减少。

不知道如何跳过和限制与这个问题有关，除了它们都涉及到mongodb。无论如何，25个结果真的没有问题。限制速度并不慢，事实上，如果小于100（默认第一批次大小），可以加快速度。跳过可能会伤害到性能，但只能通过尽可能慢地获取所有不带额外网络流量的跳过的文档。因此，我不会跳过100万个文档，但跳过100就没问题。

来源

2011-08-29 20:41:04 mstearn

谢谢。我曾经想过批量重命名是一个缺点，但你是对的 - 它会比较少见，所以不那么重要。跳过/限制与模糊相关，因为它涉及产品和从SQL到面向文档的翻译，但下次我会单独发布问题，对不起！ :) – stewartml

你可以一个名为products收集，模型类的文档：

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

的查询来获取给出的ID，类别和子类别会是这样的产品：

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

这听起来很简单，但考虑到我对你的问题的理解，IMO应该是一个好的开始。

对于你的其他问题，有skip和limit修饰符来帮助分页。

来源

2011-08-29 17:18:42 lobster1234

谢谢，但我想你可能误解了我的问题。我正在寻找一种方法来从父类别slug和产品slug的组合中生成产品URL。我关于跳过和限制的问题也是关于性能的。 – stewartml

从RDBMS角度看mongoDB中的产品目录存储

回答

相关问题