我正在基于 OpenIcecat（Icecat 开放目录）构建产品目录，我正在寻找可能有此经验的人的建议，或者可能有其他类似服务经验的人（可能像 C-Net）。
我的问题是，填充产品目录数据库的好模型是什么？
这是我到目前为止...
- 我 GET 整个目录的 XML 提要
- 我根据类别 ID 提取有关我需要的产品的数据
- 此时，我将所有数据插入到一个表中，所以现在我有一个类似“打印机猫”的表，其中包含图像的 URL 和类别中每个产品的 XML 的 ID……很简单
这是我遇到问题/关注的地方...我发现很容易为每个 XML 文件和图像使用 GET 请求的临时脚本...然后可以将它们转储到目录中，但是 Icecat 不希望您非常大量。我的类别包含数千种（例如超过 4 万种）产品。
我觉得我需要做的是获取产品的 XML 并获取图像并存储它们。我有这种感觉是因为这是一个显而易见的解决方案，而这正是客户不断要求的……但这并不意味着它是正确的。所以，然后我可以解析单个 XML 以将描述、SKU 等提取到一个表中，这样我就可以构建目录，例如用于 Magento，稍后根据需要添加/更改等（价格、相关产品等）。 ) 似乎很容易，但是在大约 3-4k GET 请求之后，我被启动了，因为我正在抓取大量数据，一旦我拥有了整个目录（我想要的类别目录），那么获取更新就很容易了文件（XML .. 比较小）并相应地进行更改...这将是一个很好的点，但首先需要获取所有数据并首先构建产品表。
所以这就是我踢的...
一种想法是根据需要实时获取数据，但这不是客户或我自己所希望的。客户想要目录，可以理解......我注意到实时会增加性能影响并且不会（轻松地）插入许多解决方案。但是，扩展“实时”的想法……使用 XML 数据的实时 GET，然后按照一些逻辑存储数据，例如“如果本地不存在……去获取它然后存储”它; 如果它在本地存在然后检查它是否是最新的信息......如果不更新它......当然如果我要检查它是否是最新的那么存储真的没有意义数据，因为我每次都在做一个请求，无论如何......不妨把它拿下来扔掉，这似乎效率低下。
-或者-
也许一切都是实时的：产品是实时获取和显示的，当管理员查看产品以进行操作时，它会实时呈现，等等。总是根据元数据实时获取需要的东西已经从“主”目录文件中填充的数据库......描述了 Icecat 提供的整个目录，但这不会插入许多解决方案并且会影响性能，而且一些主机不会让我们无论如何都要得到...这里有很多限制，但听起来像是一个糟糕的解决方案，以确保您始终拥有超级最新的信息（虽然这里不需要）
这就是我已经要去的地方了……
我有基于主目录的元数据（超过 50 万个项目）。我已经根据所需的类别填充了表格......现在我正朝着这个方向前进：构建一个可以更好地完善我正在使用的应用程序（工具），例如单个类别。然后生成一个作业“使用类别 ID 并获取所有 XML 提要”......然后“使用 cat.ID（可能再次相同）然后获取图像”......然后，使用相同的 Cat。通过抓取 SKU、Desc.、Image 文件名等 ID 和构建产品并构建目录。在工作流程的这一点上，我拥有所有信息并且可以使用 SKU（或需要的东西）从其他提要中获取价格等，操纵描述，如果需要（SEO）或其他任何东西重命名图像。
然后我需要建立一个模型来更新来自不同提要的价格和运输重量......在这种情况下是 Synnex，但似乎更容易，因为运输和价格应该是实时的......所以不同的故事和更少的数据一次，只有我在想的购物车里的东西。
仍然不确定如何去做这件事..据说其他人已经通过翻录 Icecat 存储库为同一个客户建立了这样的目录，但从不为未来的操作等制作/提供工具......这就是我要去的地方。另外，旧目录非常陈旧/陈旧，我从未见过“证据”证明他们确实撕毁了数据并建立了目录，而不是完整的目录。
好的，以帮助解决混乱...
我使用的来源有一个存储库，其中包含许多类别的超过 600,000 种产品。我只需要大约 45,000 种产品（多个类别）。事实上，为每个文件下载 xml 文件需要几个小时，比如每小时大约 1000 个（我们从过去的经验中知道这一点）。
部分问题在于并非每个 XML 文件都完全相同，我们需要来自不同类别的不同信息。这些要求很可能会发生变化（一开始可能会更多）。所以我不能只用一个模式来存储所有这些。一旦下载了 45,000 个（左右）文件，我们只需在未来获取更改/更新。所以我真正想做的是建立一个只包含我们需要的类别的本地存储库，这样我们就可以更有效地使用它们。我们也不打算立即使用相关类别，所以我想要本地文件，以便我们回去时也这样做。