【问题标题】:Multiple Tables Vs one table for e-commerce product store combination电子商务产品商店组合的多表与一张表
【发布时间】:2015-10-07 11:22:42
【问题描述】:

我正在运营一个电子商务网站,该网站有多家商店,每家商店都有自己的产品。我目前有一个名为 product-store 的表,其中包含所有产品 id 的列表,这些产品 id 引用来自不同表的产品名称和描述、价格等及其相应的商店 id。如果多个商店携带该表,则该表可能会多次重复相同的产品。

我提出的想法是为每个商店(product-store1,product-store2)创建一个单独的表,而不是将所有商店都放在一个产品商店表中。我可以添加 100 个商店,因此可以添加 100 个这样的表。每个表的结构都是相同的,但我之所以考虑这样做是为了更好地封装来自其他商店的数据。但是,这也意味着首先为商店识别相应的表,然后再获取数据。

我需要帮助来评估这是否是一种正确的方法以及如何衡量这两种方法。

【问题讨论】:

  • 我已经修改了标签 - PHP 似乎与问题无关。

标签: mysql sql-server database-design


【解决方案1】:

将一个表拆分为多个表的充分理由很少。以下是这样做的原因:

  • SQL 针对大型表进行了优化,但不适用于许多具有相同结构的小表。 (对于小表格,您最终会得到很多部分填充的数据页。)
  • 维护是一场噩梦。添加列、更改数据类型等必须重复多次。
  • 一个简单的查询,例如“有多少家商店销售一种产品?”有问题。
  • 您不能在此表中建立外键关系,例如,获取每个商店中产品的价格或折扣历史记录。

一张桌子几乎总是最好的选择。

【讨论】:

    【解决方案2】:

    我想这还取决于产品是否可以在不同的商店共享。我不会去为 x 个商店创建 x 个表,而是一个能够保存所有信息的通用结构。

    如果是这样,您至少可以设置三个表:

    • 产品(包含所有通用产品信息,独立商店)
    • 商店(有关商店的信息)
    • store_product(将产品链接到商店)

    通过这种方式,您可以在系统中添加尽可能多的产品/商店,而无需更改数据库结构(无论如何这都很糟糕)。

    回答你的一些假设:

    • 封装来自不同存储的数据是选择不同表的数据子集。
    • 当您需要一些关于商店或产品的附加信息(一开始没有考虑到)时,通过将新表引用到商店/产品来更容易添加,而不必将这些更改乘以商店的数量。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-12-16
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-11-11
      • 2011-10-07
      • 2012-05-06
      • 1970-01-01
      相关资源
      最近更新 更多