销售订单项目明细存储，走哪条路？

Posted 2023-04-12

【中文标题】销售订单项目明细存储，走哪条路？

【英文标题】：Sales order item details storage, which way to go?

【发布时间】：2011-09-06 15:23:04

【问题描述】：

我正在使用以下混合技术或技术开发一种库存管理应用程序：mysql、C#、WPF、ADO.Net EntityFramework 4。

对于如何将销售/采购发票的详细信息存储在数据库中，我有点困惑。

这就是我以前的方式...我将详细信息作为 XML 字符串存储在 LongText 字段中。

+---------------------------------------------------+
| SalesInvoices                                     |
+---------------------------------------------------+
| int InvoiceID: primary key, auto-incretement      |
| int OrderID                                       |
| int CustomerID                                    |
| int CreatedByEmployeeID                           |
| DateTime Date                                     |
| DateTime? ShippingDate                            |
| LongText ItemsData (details, stored as XML)       |
| LongText TransactionData (details, stored as XML) |
| Double Subtotal                                   |
| Double Tax                                        |
| Double Freight                                    |
| Double FreightTax                                 |
| Double Total                                      |
+---------------------------------------------------+

但是，我在网上浏览了一下，我看到的大多数示例都有一个单独的表格SalesInvoiceDetails。所以我想知道，我的方法是否有问题，我是否应该经历切换到该方法的麻烦。

我的要求：通过SalesInvoice 表的搜索应该非常快。除非用户实际打开发票，否则我不需要搜索发票的详细信息，所以如果用户必须在这里等待一两秒也没关系。

我第一次选择我的方法的原因是因为我认为一个表中的数百万个详细信息最终会使其打开速度非常慢，如果用户决定返回更改，我将不得不担心删除和更新行某物。而且我认为为细节行设置子项并将它们存储为行并跟踪父/子关系等会有点麻烦。

所以是的，我想知道有什么好的理由让我放弃我的方法并为详细信息制作另一个表格。

【问题讨论】：

如果我理解正确，您一直认为解析 XML 字符串会比查询关系数据库表更高效。请read this article 很好地解释这种误解有什么问题。

【参考方案1】：

为什么您认为使用单独的表会很慢？我认为你需要阅读（如果你还没有）关于Database normalization、indexes 等等以获得良好的性能。要立即更新详细信息，您需要传输并插入整个 blob，而不是例如一个价格字段。

我还发现了不错的文章here。我真的很喜欢作者写的（放弃你的方法的好点）：

这不是一个坏方法，因为它记录了每位客户的每次购买。但是如果你开始问一些复杂的问题，比如：

Freens R Us 在 2002 年订购了多少 3" Red Freens？

56" Blue Freens 在德克萨斯州的总销售额是多少？

2003 年 7 月 14 日售出了哪些商品？

这是我的看法:)

【讨论】：

嘿，我只是认为当我们不断添加发票并且数量变得庞大时，它最终会变慢。无论如何，感谢您的回复，我将通读这些链接。我要勾选这个，因为你已经给了我足够的信息来做出明智的决定。