[提供](https://res.cloudinary.com/practicaldev/image/fetch/s--Qv5kT82c--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://imgur。 com/FSkeOvN.jpg)

电子商务数据库在复杂的货币系统中跟踪不可预测的人类行为者:归根结底,您希望在获得第三方授权的付款后将产品交付给您从未见过的人。处理付款、添加产品、跟踪订单和处理回扣都是您的电子商务数据库必须处理的复杂功能,才能实现该目标。

本文将在之前的文章的基础上,讨论可扩展 SQL 数据模型和NoSQL 数据模型,展示如何构建混合数据模型。您将学习如何利用各种数据库引擎的优势专门处理更复杂的电子商务交互。

想象一下,用户在批量购买后打折的十几件商品中退回一件。用户忘记密码,退回的包裹到达错误的供应商仓库。当这个返回到达时,您的数据库模型必须处理复杂的工作关系网络,以将所有内容放回正确的位置。您可能还需要跟踪导致此结果的事件链,以便向客户发送满意度调查。

本文将制作一个可以在这种情况下大放异彩的数据库。

为您的用户建模

任何电子商务网站的基础都是其用户。他们执行每一个动作,每一个动作都是一个复杂的、无法控制的人。用户搬家,更改付款方式,忘记通知他们经常光顾的商家,然后要求退款。

幸运的是,您只需要知道关于用户的一组非常固定的事实。很少有关于人的新类型的事情需要了解,但可以通过多种方式查询它们。用户数据的一些常见访问模式是添加新地址或更新电子邮件地址或密码。

因为它们具有一组具有多种访问模式的固定数据,所以用户数据非常适合结构化 SQL 数据存储。此外,用户信息是您业务分析数据的最佳来源之一。例如,您可能希望对购买您产品的用户执行临时查询,从而进一步巩固 SQL 对您的用户数据的适用性。

以下用户模型实现了电子商务网站必须支持的一些复杂模式,例如重置密码、添加多个送货和帐单地址,以及跟踪用户在各个页面上花费的时间以及他们点击了什么页面。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--LvP9eGTO--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://imgur.com/ bGaRNsc.png)

在构建模型时,请注意您不需要预先收集所有信息。当用户首次注册您的应用程序时,您无需收集用户的送货地址或帐单地址。例如,Fabric使入职流程保持简单,只需在注册时询问电子邮件、姓名和密码。然而,正如我们在我们的电子商务网站故障中看到的那样,许多企业使这一步复杂化,使人们难以在线结帐。

接下来,让我们看看您将向用户展示什么。

您的产品目录

产品目录代表可供用户购买的每件商品:物品、订阅或捐赠等级。所有这些选项都有不同的结构,需要跟踪稍微不同的东西。订阅具有功能或访问级别,而对象具有大小、颜色和图像。产品目录中可以包含的内容有很大的灵活性和多样性。

在 NoSQL 中混合

与经过结构化、规范化和优化以节省存储空间的 SQL 数据不同,NoSQL 数据经过非规范化和优化以节省 CPU 资源。这意味着它对于数据分析应用程序(例如在页面上跟踪用户)来说是一个糟糕的选择,但是当您完全了解访问模式时,它对于高吞吐量应用程序来说是一个很好的选择。

NoSQL 非常适合托管产品信息。大多数情况下,产品信息只是简单地显示给用户,如果购买了商品,则可用库存可能会更新。 NoSQL 数据库非常擅长创建实例化视图,其中填充来自单个往返查询的数据。

使用 NoSQL,您的目标是将应用程序用于页面的所有数据存储在单个文档中。这是一个例子:

[](https://res.cloudinary.com/practicaldev/image/fetch/s--KLuFaaZV--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://imgur. com/tuRzOtw.png)

使用此数据模型,当客户请求产品页面时,您的应用程序会在一次往返中请求并接收呈现页面所需的一切。客户可以检查的每个变体的图像、价格、选项和尺寸都存储在一个文档中。这意味着数据层不会花费 CPU 时间来查找各种表并将其组合在一起,从而使 NoSQL 请求非常具有水平可扩展性。

NoSQL 的其他好处之一是数据以 Web 理解的格式 (JSON) 返回,这可以省去为您的产品编写自定义对象关系映射器 (ORM) 的麻烦。

缓存什么

开发人员可用的数据存储选项之一是内存存储,例如Redis。对于任何缓存策略,目标都是通过将以前在数据层中执行的事务移动到访问速度更快的硬件(如 RAM)来保留 CPU 和磁盘 I/O。

使产品目录成为 NoSQL 数据存储的良好候选者的特性也使其成为在内存数据存储中缓存的良好候选者。数据被大量读取并且很少更改,因此缓存将在保持准确性的同时节省磁盘时间。

缓存也是会话管理的一个很好的解决方案,在电子商务环境中,存储用户当前的购物车。无需在每次用户发出请求时在数据库中查找 cookie 或返回购物车中的所有商品,您可以将该工作负载推送到缓存层并实现请求响应时间,如果由您的数据库。

支付模式

支付系统允许用户通过将您的网站链接到支持支付的各种服务来购买和接收您的产品。这是任何电子商务网站的重要组成部分,它必须运行良好以确保客户满意度。结帐流程中断通常会破坏交易。

此步骤还对存储何种数据以及如何存储数据有最严格的安全要求。一般来说,不要存储太多信用卡信息,并确保对保存的任何可识别支付信息进行加密,例如卡标识符。您的支付模式存储的数据越少越好。它减少了您的法律责任并帮助您遵守支付卡行业数据安全标准 (PCI-DSS)。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--myPmIqCr--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://imgur.com /EisVQzc.png)

理想的付款表不包含太多信息。当用户在输入付款信息后最终点击_购买_时,您的应用程序几乎可以绕过您的数据层。相反,它将请求传递给支付处理器,后者将处理它并返回结果。

如果您认为您需要存储支付信息以备将来使用,您的支付处理器很可能会选择存储该数据,并会为您提供一个唯一的、不可识别个人身份的令牌以供下次使用。

将您的产品发送给客户

订单模型是您的数据库的一部分,它跟踪将产品交付给客户的过程,从他们第一次表达兴趣的那一刻起,一直到将物品送到他们手中。订单可能涉及对网站的持续访问或处理离散事件,例如向客户发送产品。

流畅的订单流程对于创建人们愿意重复的用户体验至关重要。该顺序是我们所有其他数据库模式的使用位置。

这是一个产品的订单:

[](https://res.cloudinary.com/practicaldev/image/fetch/s--R9Xlkzvt--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://imgur.com/en6WAVI .png)

您会注意到折扣和价格信息已从我们的 NoSQL 数据模型复制到cart_item表中。 NoSQL 模型表示客户进入页面时显示给客户的折扣,保存的价格和折扣是实际应用于商品的折扣。

如果价格或折扣发生变化,您需要确保记录实际支付的价格。请注意 NoSQL 和 SQL 组件之间的此类故障线。

结束

重新审视本文中呈现的初始场景,让我们看看模型是如何拼接在一起的。用户忘记了密码,但我们用户的模型会处理更新密码。退回的包裹已到达错误的供应商仓库,但我们在订单中跟踪了原始来源,因此我们可以将其转发到正确的目的地。计算退款很棘手,但因为我们跟踪订单级别的折扣信息,我们可以运行临时查询来确定适当的退款。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--0rBGUEzI--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://imgur.com /9vuynE2.png)

在规划数据模型时,请记住 SQL 针对高效存储结构化数据和对数据执行任意查询进行了优化,而 NoSQL 针对高效交付非结构化数据进行了优化。

电子商务网站可能面临许多此模型未涵盖的挑战,例如处理订阅,根据用户行为对商品](https://fabric.inc/offers)应用[折扣,以及跟踪库存。Fabric拥有一支多年构建电子商务数据模型和网站的专家团队,为这些复杂的问题提供简单的解决方案。