mysql - 电子商务的数据库设计问题

假设我有两个“东西”可以卖: service 和 product 。每个都用一个表格表示，该表格捕获了它们的独特属性(例如，服务可能具有每小时费率，而产品可能具有每单位价格等)。

每次进行销售时，假设无论服务或产品是否已售出，我都需要获取有关销售的完全相同的数据。我该如何建模？

方法 1:

我创建了一张表来保存每次销售的详细信息

我创建了两个“映射”表来连接产品或服务与销售表

所以，像这样:

TABLE: product
- product_id (PK)

TABLE: service
- service_id (PK)

TABLE: sale
- sale_id (PK)

TABLE: product_sale
- product_id (FK)
- sale_id (FK)

TABLE: service_sale
- service_id (FK)
- sale_id (FK)

方法 2:

跳过映射表，只用单独的表来记录产品和服务的销售额。

TABLE: product
- product_id (PK)

TABLE: service
- service_id (PK)

TABLE: product_sale
- product_sale_id (PK)
- product_id (FK)

TABLE: service_sale
- service_sale_id (PK)
- service_id (FK)

我觉得方法 1 会更好，因为我需要生成如下报告:

给定期间的总销售额

每个销售人员的总销售额

等

最佳答案

由于您列出的原因，您的方法 1 比方法 2 更有利。能够收集任何类型的所有销售数据，并在一次销售中包含多个项目。方法 2 建议产品和服务一次只销售 1 个，而不是捆绑在一起。但我想知道您为什么要首先将产品和服务分开？ (这将是行业特定的，具体取决于您的需求)。大多数电子商务系统和小型企业会计系统使用带有一个产品表的更简单的模型。

所以这是我使用一张产品表对您的问题的官方回答:

构造 [product] 表以具有 PricePerUnit 和 UnitOfMeasure
(可以是小时，可以是每个，可以是成对，可以是预订率
标准服务)。这可以充分描述定价
大多数小公司的产品/服务之间的模型差异。

现在在您的 [product_sale] 表中(在我的
lingo)，添加注释字段。在这个领域你可以写
有关所售产品/服务的详细信息。在服务的情况下，
您可以输入一些注释供客户引用，例如
“执行X服务，调整B小部件并完善C调优
旋钮”。

所以在这个简单的例子中你有三个表:

[products] - 包含产品和服务的主数据或“目录”，包括某些计量单位的定价。

[发票] - 包含您的销售信息或发票标题，包括日期、交易 ID、可能是销售人员等。

[invoicelineitems] - 以多对多的方式将发票与具有两个外键的产品连接起来。

这是大多数现成的电子商务系统和小型企业会计系统的工作方式。

如果您需要 super 特定的跟踪，您肯定可以变得更复杂，但您需要通过解释为什么每单位价格模式不适用于您的用例来证明成本和复杂性是合理的。 (汽车经销商是一个示例，其中服务的跟踪方式与正常情况完全不同，单独表中的服务/产品都与代表您汽车的一个“问题”或“投诉”的行项目相关联。每个行项目都有一个产品组件和一个服务组件。)

更新: 正如@Doug 指出的那样，我的原始答案似乎不够清楚。当您为销售创建发票时，当前的 PricePerUnit 与 QuantitySold 字段和任何其他对产品主数据快照很重要的数据一起复制到 InvoiceLineItem 记录，以防您需要撤消交易。这可确保发票始终保持相同的总额，即使将来产品价格发生变化。它还允许您在客户退货时冲销发票，并确保无论当前价格如何，客户都能获得与支付相同的金额。

关于mysql - 电子商务的数据库设计问题，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/7962338/