Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 5 down vote favorite

I have worked on several ordering systems. Every one of them has tracked the shipping and handling as part of the order header rather then tracking it as a line item. To me, it would make more sense to keep them with the line items, even if the information is not displayed that way to the user. What are the reasons for keeping them in the header?

share|improve this question
Arguably, it could also be defined as an extra field on each line item row. Since each item would contribute some amount to the S&H costs unless you had a flat shipping rate. – JohnFx Feb 25 '11 at 18:24
In most of the systems I have worked on it is a flat fee or a caculated fee based on some thing other then the actual prduct shipped. But you are correct it could be. – Erin Feb 25 '11 at 18:25
Line items, just as any type of collection, should be filled with siblings. Shipping charges are not siblings to order items. – NickC Feb 25 '11 at 18:58

3 Answers

up vote 5 down vote accepted

Let me ask you this. If I order 100 items and then change my mind and ask to have only 50 before the item is shipped would the shipping go down? IN other words is the shipping a per order charge that won't change no matter what is ordered or is it calculated based on the individual items in the order. If you ship heavy things, it is likely to be based on the items ordered and thus stored there. If you ship lighter things, likely the charge is standard per order and should be stored in the parent table.

share|improve this answer
My experience has been it is a flat fee. – Erin Feb 25 '11 at 18:26
4  
@Erin, flat fee is a convenience shippers have come up with to simplify things for individuals and small businesses. For large businesses, it's more efficient to use a more complex method, so small shipments pay less than the average and large pay more instead of everyone paying the average. Amazon, for example, charges a rate per shipment based on the kind of items, then an additional rate per item. When shipping cost is an aggregate property of the entire order, it makes sense to keep it at the order level. Flat fee works with that model, but not vice versa very well. – Karl Bielefeldt Feb 25 '11 at 18:46
@Karl Bielefeldt, thanks for the details. That does make more sens to me. – Erin Feb 25 '11 at 20:35
up vote 1 down vote

I think the reasoning is two fold for placing the shipping, handling, tax, etc as calculated fields on the header.

  1. The developers may prefer that style, having worked in legacy applications I've noticed that a lot of developers from the mid-90's tended to use a flat table design with calculated fields.

  2. The designers of the software could be unaware of using a more normalized approach to software design specifically in the domain. If I was presenting a run of the mill UI Shipping, Hanlding, Tax, are generally summed values displayed as part of the order totalling process.

Concievably the authors of the code do not differentiate between a domain model and a view model or the view aspect of the domain model. Assuming that the two are tightly coupled its understandable.

If I was to give my opinion as to which route is best i'd go with a normalized approach of providing the shipping, handling, tax, and other fees as line items to cut down any calculated fields on the order header. I'd then provide them as a summed value in a ViewModel if necessary but only as a product of the UI's display never as a method of data storage.

share|improve this answer
up vote 1 down vote

Think of it like this: a single shipping order ships multiple items to a single address. From that simple phrase you can deduce the entity relationships between the various bits of data. A shipping order has a one-to-many relationship with the items, thus the master-detail form. On the other hand, a shipping order has a one-to-one relationship with the shipping address, so they are part of the same form and in a normalized DB they would be part of the same table.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.