最好的方法 [英] best approach

问题描述

900万产品

4个库存配送中心（基本上是4个库存）

4 distribution centers for inventory (basically, 4 inventories)

什么是最佳方法？我阅读了Ravi的笔记，但是关于目录集，虚拟目录以及目录的容量。我只是想知道什么是推荐的方法。

what is best approach? I read Ravi's notes but on catalog set, and virtual catalogs, as well as capacity of catalogs. I'm just wondering what is reccommended approach.

这是一条路线：

1。将基本目录分成300万件产品，分为三个基本目录

1. break up the base catalogs into 3 million products a piece for three base catalogs

2。这将是第一组，其目录设置与我预期的客户主仓库相匹配。

2. that would be group one, with a catalog set to match the i intended primary warehouse of the customer.

3。所有基础都将映射到库存目录。我假设与basa目录具有相同的容量，因此有三个库存目录。

3. all the base would be mapped to inventory catalogs. I assume same capacity as basa catalogs, so three inventory catalogs.

4。因此，我们可以通过填充包含的catalog_set来告知用户分配的仓库。该仓库的库存....好的，这是最简单的部分。

4. So, we can tell what warehouse the user is assigned by populating the catalog_set that holds  inventory for that warehouse.... ok, that's the easy part.

由于100万产品限制，要扩展到4个配送中心并节省虚拟目录的数量。

To scale out to 4 distribution centers and save the number of virtual catalogs, due to 1 million product constraint..

5。为其他3个仓库再创建3个目录集。我可以做两件事之一，创建9个（由于每个100万个）虚拟目录 对于每个目录集的三个基础，它将产生27个目录，或者，只为每个目录设置3个基数..所以，
9个基本目录。每个目录集都适用于不同的配送中心

5. create 3 more catalog sets for the other 3 warehouses. I can do one of two things, create 9 (due to 1 million in each) virtual catalogs  for the three base for each catalog set which would make 27 catalogs, or, just make 3 more base for each.. so, 9 more base catalogs. Each catalog set is for a different distribution center

以上操作非常简单，我们已经成功且简单地制作了原型。经历的问题是，每个目录集有900万个产品，超过4个目录集，即3600万。将使用模式Commerce Server似乎
提供。 现在，阅读Ravi关于商业服务器容量的说明，它实际上仍然不到1％。

the above is fairly simple to do, and we've prototyped both successfully and simply. the problem that is percieved is, each catalog set has 9 million products, over 4 catalog sets, thats 36 million. that would be using the pattern Commerce Server seems to provide.  Now, reading Ravi's notes on capacity of commerce server, it's really still less than 1%.

..或者只保留3个基数并横向分配所有4个仓库的库存架构自定义checkinventory是一个更好的选择吗？

..or do would keeping just 3 base and horizontally exending the inventory schema for all 4 warehouses and do a custom checkinventory be a better option?

 

谢谢，

 

Eddie

 

 

推荐答案

我通常不喜欢直接使用基本目录。虚拟目录有其优点。如果不存在，虚拟目录允许您添加规则以排除产品或类别，其类似于"取消发布"功能。实际上，在您暂时想要从网站上删除产品然后在某个时候将其恢复的情况下，它通常是
。在产品实际上保留在基本目录但实际上不可用的情况下，排除规则非常方便。

I usually prefer NOT to use base catalogs directly. Virtual catalogs have their advantages. If nothing, the virtual catalogs let you add rules to exclude products or categories which kind of works like an 'unpublish' feature. In reality, its common to be in a situation where you temporarily want to remove a product off the web site and then have it back at some point in future. Exclude rules are quite handy in such situations where the product physically remains in the base catalog but its virtually not available.

然而，一个关键的决定是让这些风险投资"实现"或不。如果您实现它们，那么您将不得不经常重建它们（在对基本目录进行任何更改时）。另外，我认为实现一个包含一百万美元产品的虚拟目录将是一项艰巨的任务。另一方面，保留虚拟目录未实现可能会对浏览性能产生负面影响。

However, a key decision for you will be to have these VCs 'materialized' or not. If you materialize them, then you'll have to rebuild them frequently (upon making any change to the base catalog). Plus, I believe materializing a virtual catalog containing a million products will be a heavy task. On the other hand, leaving the virtual catalogs un-materialized may have negative effects on browsing performance.

这篇关于最好的方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！