从 RDBMS 角度看 mongoDB 中的产品目录存储
我有一个产品页面，其 URL 格式为 http://host/products/{id}/{seo-Friendly-url}，其中“seo-Friendly-url”部分可能是类似类别/子类别/产品。
产品控制器获取具有指定 ID 的产品，然后确保后面的 URL 对于该产品来说是正确的 - 如果不是，则用户将被重定向到适当的 URL（尽管商店中的所有 URL 都会正确生成，但重定向只是为了在用户输入错误或 Google 抓取后 URL 发生变化等情况下维护规范的 URL。 ID 可确保快速查找产品，末尾部分可确保关键字进入 URL。
为了检查 URL，我有一个 SQL 视图，它利用递归公用表表达式将产品 URL 块与其父类别 URL 的 URL 一直连接到层次结构（通常只有 3 层）。
我最近遇到了面向文档的存储，我可以看到它在各种情况下都非常有用（例如，我的产品实体目前在不同的表中具有标签、多重购买价格和属性等）。
那么我的问题是如何在 mongoDB 中实现上述功能，或者是否有更好的方法来考虑它？天真的方法是单独检索层次结构中的每个类别，但我假设这会很慢。
相关：我在文档中读到，对于大型结果集，跳过/限制速度很慢 - 对于零售网站类别中可能存在的最多 10 页 25 个产品，这会很明显吗？
I have a product page with an URL of the form http://host/products/{id}/{seo-friendly-url}, where the "seo-friendly-url" part may be something like category/subcategory/product.
The products controller gets the product with the specified ID and then ensures that the URL that follows is correct for the product - if it isn't the user is redirected to the appropriate URL (all URLs in the shop are generated correctly though, the redirect is just to maintain a canonical URL in the case of mistyping by the user or the URL changing since Google crawled it etc). The ID ensures fast product look-up, and the part on the end ensures keywords make it into the URL.
To check the URL, I have a SQL view which utilises a recursive common table expression to concatenate the product URL chunk with the URLs of its parent category URLs all the way up the hierarchy (generally just 3 deep).
I've recently came across document oriented storage and I can see it being very useful in a variety of situations (for example, my product entities have tags and multibuy prices and attributes etc all in different tables currently).
So on to my question - how can I achieve the above functionality in mongoDB, or is there a better way to think about it? The naive way would be to retrieve each category in the hierarchy individually, but I'm assuming that would be slow.
Related: I've read in the docs that skip/limit for is slow for large result sets - would this be noticeable for the maximum of say 10 pages of 25 products each likely to be present in a retail website category?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为最好的选择是将完整的块与产品一起存储。然后，当您收到产品时，只需检查 slug 是否匹配，如果不匹配，则重定向。现在，需要权衡的是，如果您想重命名一个类别，您将需要执行批处理作业来查找该类别中的所有产品并更改其名称。好消息是类别重命名将比视图少得多（希望如此），因此您的总负载将会减少。
不确定skip和limit与这个问题有什么关系，除了它们都涉及mongodb。反正25个结果确实没问题。 Limit 并不慢，事实上，如果小于 100（默认的第一个批量大小），可以加快速度。跳过可能会损害性能，但只会使其变慢，就像您在没有额外网络流量的情况下获取所有跳过的文档一样。因此，我不会跳过 100 万篇文档，但跳过 100 篇文档就可以了。
I think your best option is to just store the full slug with the product. Then when you get the product just check to see if the slug matches and if not, redirect. Now, the trade-off is that if you want to rename a category you will need to do a batch job to find all products in the category and change their slugs. The good news is that category renames will be much less common than views (hopefully) so your total load will be reduced.
Not sure how skip and limit are related to this question, except that they both involve mongodb. Anyway for 25 results it's really no problem. Limit isn't slow and in fact can speed things up if less than 100 (default first batch size). Skip can hurt performance, but only by making it as slow as if you fetched all skipped documents w/o the extra network traffic. Therefore I wouldn't skip 1 million docs, but skipping 100 would be fine.
您可以对一个名为
products的集合进行建模，其文档如下：给定 id、类别和子类别的获取产品的查询将类似于：
这听起来很简单，但考虑到我对您问题的理解（IMO）这应该是一个好的开始。
对于您的其他问题，有
skip和limit修饰符可以帮助分页。You can model a collection called
products, with the document like:The query to get the product given the id, category and subcategory would be something like:
This sounds pretty simpleton but given my understanding of your question IMO this should be a good start.
For your other question, there are
skipandlimitmodifiers to help with pagination.