销售订单项详细说明存储,选择哪条路径
本文关键字:选择 路径 存储 说明 单项详 | 更新日期: 2023-09-27 18:07:58
我正在使用以下混合技术开发一种库存管理应用程序: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
。所以我在想,是不是我的方法出了什么问题,我应该麻烦地转换到另一种方法吗?
My Requirements:通过SalesInvoice
表的搜索应该非常快。我不需要搜索发票的详细信息,除非用户真的打开了发票,所以如果用户在这里等一到两秒钟也没关系。
我第一次选择这种方法的原因是因为我认为在一个表中包含数百万个细节最终会使它的打开速度非常慢,并且如果用户决定返回更改某些内容,我将不得不担心删除和更新行。而且我认为为详细行设置子项并将它们存储为行并跟踪父/子关系等会有点麻烦。
所以,是的,我想知道是否有什么好的理由为什么我应该放弃我的方法,并为细节制作另一个表
为什么你认为使用单独的表会很慢?我认为你需要阅读(如果你还没有)数据库规范化,索引等,以获得良好的性能。现在要更新详细信息,您需要转移并插入整个blob,而不是例如一个价格字段。
我也在这里找到了很好的文章。我真的很喜欢作者写的东西(放弃你的方法很好的一点):
这不是一个坏的方法,因为它记录了每个顾客的每一次购买。但是如果你开始问一些复杂的问题,比如:
多少个3"2002年,Freens反斗城订购了Red Freens吗?
56"德州的蓝鹰乐队?
2003年7月14日有哪些商品出售?
这是我的观点:)