电子商务数据库设计

构建电子商务是我们构建的最著名的网络应用程序之一，因为它非常有名、众所周知，并且对它的需求比以往任何时候都更大，用于在线订购和运送产品到您的家中。

我在构建许多电商应用程序时面临的最大挑战之一是，随着客户要求的功能越来越多，我们必须添加更多功能，这会带来复杂性。这让我开始思考我的架构，尤其是数据库设计的利弊，并开始问自己许多问题，例如：我的设计是否符合这些需求？我是否获得了尽可能简洁的结构？这是否会影响性能和数据加载效率？

直到此刻我写这篇博客时，我才得出结论，这个数据库设计最适合我之前遇到的需求（直到我得到了一个有更复杂要求的新项目🤡）。

我们的项目描述和要求

首先，与任何应用程序一样，我们的电商应用也允许用户注册并登录。每个用户都有一个或多个地址。他们还拥有收藏夹或愿望清单、订单列表（用于列出订单及其状态）以及购物车列表（用于列出所有可订购的产品）。

我们有类别和子类别（2 个级别的类别），每个类别都有名称和描述。

当然，我们有产品，其中包括很多东西：

产品的基本信息，如：名称、描述、价格、摘要、封面图片等。
产品图库包含许多产品图片。
每种产品可能具有一些属性，例如尺寸和颜色。
一些具有多种颜色的产品将为每种颜色分别提供图片库。
每种颜色、尺寸或两者的价格可能都不同。假设蓝色 T 恤的价格为，20$但红色 T 恤的价格为22$。甚至 xl 蓝色 T 恤的价格为，22$但 XXL 蓝色 T 恤的价格为26$。
每种颜色和尺寸的库存数量有限，例如我们可能有 XXL 蓝色 T 恤 3 件，但 XXXL 蓝色 T 恤只有 1 件。

当用户下订单时，将选择订单中的一个地址，并且他可以使用任何支持的方式在线支付，例如签证或其他方式（将与支付网关集成）。

当订单发货时，所有产品的数量都会减少。

现在，这就是项目的全部要求，让我们开始思考吧。

数据库设计

正如我们从上一节中注意到的那样，最复杂的部分是产品，游戏就在这里进行 xD。

让我们从数据库设计的开始开始。

用户表

让我们从用户表及其相关信息开始。

这里我们只有 2 个表，一个用于用户信息详细信息，另一个用于与用户关联并one to many使用关系链接的地址user_id。

类别表

现在在类别表中，我们有 2 个表，一个用于主类别，另一个用于子类别。子类别表与one to many关系中的类别相关联。

产品表

现在，让我们从一个简单的结构开始，其中包含产品的基本信息，并与类别关联（将many to many与子类别表关联）。参见下图。

让我们尝试更深入地了解，如上所述，产品将具有许多不同的属性（在我们的例子中是颜色和尺寸），并且它们可能具有不同的价格范围，因此让我们从产品表中删除价格列，因为它将链接到其他表。

正如我们上面注意到的，我们添加了新的表，product_attributes它将保存所有产品属性类型以及不同颜色和尺寸的值。

然后将创建product_skus将产品和属性链接在一起的表，因为我们添加了 2 列，它们都指向product_attributes表，但一列用于颜色，另一列用于尺寸（如果需要，我们可以添加更多）。

注意：我们可能会将product_attributes表拆分为另外 2 个表，例如product_colors，和，product_sizes但我认为product_attributes表的想法更容易扩展，因为我们可以在同一个表中添加更多属性大小，但只会在products_skus表中添加一列。

每个product_skus实体都有一个价格和数量值，并且每个属性的变化可能会有所不同。