什么是订单/发票信息的建议数据库架构?

时间:2012-07-21 00:48:17

标签: database-design

我必须对电子商务系统进行一些更改以添加一些额外的信息,并希望借此机会进行一些改进并使其更加灵活。当客户下订单时,我们必须在订购的每件商品中存储几项信息;例如,产品价格,运费,收税,以及所做的任何调整。

我正在辩论是否应该离散地存储这些字段,例如(简化示例):

ORDER_LINE_ITEM
    OrderLineItemID
    ProductID
    Qty
    Price
    Shipping
    Handling      
    SalesTax
    Adjustment

例如,我可以计算客户支付的总价格:

SELECT Qty*(Price+Shipping+Handling+SalesTax) As TotalCollected FROM ORDER_LINE_ITEM

或者如果我应该使用更间接的结构:

ORDER_LINE_ITEM
    OrderLineItemID
    ProductID
    Qty

ORDER_LINE_ITEM_ENTRIES
    OrderLineItemEntryID
    OrderLineItemID
    EntryType
    Value

例如:

1 | 1 | Price      | $10
2 | 1 | Shipping   | $5
3 | 1 | Handling   | $1
4 | 1 | SalesTax   | $1
5 | 1 | Adjustment | -$3.50

这样做的好处是我可以在以后存储其他信息而无需更改表模式。但是,检索信息和运行报告会变得更加复杂和缓慢。

是否有将此信息存储在订单/发票数据库中的最佳做法?

提前致谢,

3 个答案:

答案 0 :(得分:7)

您可以在Database Answers找到几个相当标准的数据库设计来解决常见问题。 Click here用于他们的数据模型页面。

有几个样本模型与发票有关。

答案 1 :(得分:1)

我会采用混合方式,同时具备:

ORDER_LINE_ITEM
    OrderLineItemID
    ProductID
    Qty
    Price
    Shipping
    Handling      
    SalesTax
    Adjustment
    Extras

ORDER_LINE_ITEM_ENTRIES
    OrderLineItemEntryID
    OrderLineItemID
    EntryType
    Value    

然后做

SELECT Qty*(Price+Shipping+Handling+SalesTax+Extras) As TotalCollected FROM ORDER_LINE_ITEM

然后,您可以使用单个表格大部分时间工作,但如果您需要搜索项目的详细信息(或添加影响价格的新事物),则可以执行此操作(使用额外字段)。

在另一个主题中,我会考虑是否所有这些字段都应该在ORDER_LINE_ITEM上。我不知道您的业务,但在我所知道的情况下,运费,处理甚至价格都是按整个订单计算的,而不仅仅是一个项目(而且并不总是可以将其拆分为单独的项目)。拥有“管理员”用户或密码也很常见,他们可以出售任何他想要的东西,为所有内容输入任意字段,并忽略所有正常的业务规则。所以你可能会考虑这样做:

ORDER_LINE_ITEM
    OrderLineItemID
    OrderId
    ProductID
    Qty

ORDER
    OrderId
    ItemsTotalPrice
    Shipping
    Handling
    SalesTaxes
    Adjusment
    FinalPrince

您可以创建详细信息表格,以指定订单价值(税金,运费等)的创建方式......

一般来说,我发现最好的方法是让一个实体拥有所有订单(或操作)的最终信息,然后是指定如何计算“总”值的其他子实体。 / p>

答案 2 :(得分:0)

从概念上讲,最好是你的第二个方法,因为订单信息不属于产品,产品可能不存在“Shipping”,“taxex”,此外,你这样存储的数据少,不需要重复产品信息。

ORDERITEM
    OrderItemID
    ProductID
    Qty

ORDERITEMENTRIES
    OrderItemID
    EntryType
    Value