绘制产品和商店地图的策略,也许还有国家?

发布于 2024-10-09 01:04:36 字数 293 浏览 1 评论 0原文

我的看法是: 据说一个国家有 1000 万家商店(实际上更多)。 这 1000 万家商店中至少销售 5000 万种独特的产品。 (现实中又多得多)。

因此,为了绘制出来,我猜它会类似于: pk_id、store_id、product_id

但这样我们每个国家/地区将有 5 亿行 x 甚至需要 100 个国家/地区 = 500 亿行。不是一个非常有效的表来进行查找、读/写等。

有没有更好的方法来映射产品、商店,然后将国家/地区也添加到其中?

我还没有添加在线商店或在线产品,它们的大小几乎是这个大小的三倍。

The way i see it:
There are say 10 million stores in a country, (much more in reality).
There are atleast 50 million unique products being sold across these 10 million stores. (again much more in reality).

So to map this out I guess it will something like: pk_id, store_id, product_id

But this way we will have 500 million rows per country x even take 100 countries = 50 billion rows. Not a very efficient table to be doing lookups, read/writes etc from.

Is there a better way to map product, stores and then add countries also in the mix?

I have not added in online stores or online products which will almost triple this size.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

淡淡離愁欲言轉身 2024-10-16 01:04:36

每家商店都位于特定的国家/地区。

您可以使用一个表来存储商店和国家/地区之间的关系,并使用另一个表来保存商店和该商店中销售的商品之间的关系。

为了提高查找效率,您需要添加索引。

Each store is in a specific country.

You can use one table to store the realtionship between stores and countries, and another table to hold the relationship between stores and items sold in that store.

To make lookups efficient you need to add indexes.

七月上 2024-10-16 01:04:36

不要将所有内容都存储在一张表中。您应该这样做:

  1. 将产品存储在 products 表中(product_id 等/索引 Product_id)
  2. 将商店位置和国家/地区存储在单独的表中(id、store_id、country_id / 创建一个名为 store_country 的索引,其中包含列 store_id,country_id)

这样您就可以拥有 5000 万种产品(5000 万行)和 38 个(随机)国家/地区的 5000 万家商店,1,900,000,000 行假设每个商店在每个国家都有一个位置,并且每个商店销售每种产品(不现实) 。

我喜欢大数字。

Don't store everything in one table. Here's how you should do it:

  1. Store products in a products table (product_id, etc / Index product_id)
  2. Store store locations and countries in a separate table (id, store_id, country_id / make one index called store_country containing the columns store_id, country_id)

This way you can have 50 million products (50 million rows) and 50 million stores in 38 (random) countries, 1,900,000,000 rows assuming every store has a location in each country and each store sells every product (unrealistic).

I like big numbers.

我乃一代侩神 2024-10-16 01:04:36
  • 一张产品表
  • 一张国家/地区表(使用 ISO 国家/地区代码作为 PK)
  • 一张商店表(包括国家/地区表的外键)
  • 一张用于映射产品和商店的表。使用 {product_id, store_id} 作为主键)

如果您的公司与大多数公司类似,我想您会发现并非所有产品都在所有商店中销售,从而形成映射表比你预期的小得多。 (如果所有商店都销售所有产品,则不需要映射表)

  • One table for Products
  • One table for Countries (use ISO country code as PK)
  • One table for Stores (include a foreign key to the Countries table)
  • One table for mapping Products and Stores. Use {product_id, store_id} as primary key)

If your company is anything like most of the companies out there, I think you will find that not all products are being sold in all stores, making the mapping table much smaller than you anticipate. (If all stores sell all products always you don't need the mapping table)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文