Order / Basket relationship

[John Whish]

Hi,

I've built an shopping cart using ORM and currently the user has a
basket which is persisted, when the user starts the checkout process,
then an Order object is created and the Basket is associated to the
Order. This all works fine.

The problem I have is that when the order completes, I clear the
Basket (which maps to the Baskets table) when the order completes and
store the ordered items in a OrderLine object (which maps to the
Orderlines table). I do this because I want to keep the Basket table
nice and light and not concerned with historic data (passed orders).
The trouble with this is that I then have a 1 to 1 relationship
between an Order and a Basket (until the order completes) and also a 1
to 1 relationship to the OrderLine object (for completed orders).

Is there a more elegant solution to this that I'm missing?

Thanks.

- John

[Bob Silverberg]

In the most recent system that I wrote that uses ORM and requires
baskets/orders I just have one entity: order. It also serves as the
basket. If there are properties that I only need for the basket, but
I don't need to persist for the order then I make them non-persistent
properties.

This worked well for me,
Bob

> --
> You received this message because you are subscribed to the Google Groups "CFCDev" group.
> To post to this group, send email to cfc...@googlegroups.com.
> To unsubscribe from this group, send email to cfcdev+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en.
>
>

--
Bob Silverberg
www.silverwareconsulting.com

[Peter Bell]

I've been doing this ever since I started writing e-comm systems in the 90's. I'm still not convinced I love the approach as for high volume sites sharing the table between often updated carts and historic orders isn't ideal. I think going forwards I'm gonna look at using a key-value store for the baskets and a relational db for orders, but it's gonna have to wait for a client with some kind of scaling requirements - or maybe I'll write a sample as a demo for NoSQL presentations . . .

[Paul Vernon]

I tend to keep the basket in the session then, when it comes to sending the order to the payment gateway I serialise the basket object and store it in a temp orders table. Upon return from the payment gateway, whether it's a positive or negative result, the data is pulled out of the temp orders table and deleted from there. If the order is approved, I store the order details in the db and serialize the transaction details into one field within the order table and serialised the basket into another column. I used to use WDDX but now use JSON.

By doing this, I only have one record that is stored permanently per order which is an "order record" which contains a full copy of the original basket and the transaction information as sent back from the payment gateway. The basket stores tax rates and costs of each item etc. so that when a basket is de-serialized, it shows the rate of tax as it was when the order was made. This is great in the UK as in the last couple of years, our VAT rate has gone from 17.5% to 15% to 17.5% and in January it's going up to 20% so for online e-commerce stores that have been going for a while, being able to store this sort of data for tax reasons is very important.

Paul

[Peter Bell]

On Dec 9, 2010, at 11:04 AM, Paul Vernon wrote:

> By doing this, I only have one record that is stored permanently per order which is an "order record" which contains a full copy of the original basket and the transaction information as sent back from the payment gateway. The basket stores tax rates and costs of each item etc. so that when a basket is de-serialized, it shows the rate of tax as it was when the order was made.

This is essential for any e-comm system. It's one of those cases where normalization doesn't work. Generally you don't want to have pointers to products, tax rates, shipping calculators, discount codes, addresses, gift certificates or anything else as the items you point to can change over time. Other approach is to implement versioning so you point to an immutable version of a product or address. That works, but it's typically more work than just having a denormalized copy of all of the info in the order and order item tables.

Best Wishes,
Peter

[John Whish]

Thanks Bob, Peter and Paul,

I persist the basket instead of using a session so that the user can return later and still have the items in the basket (identified by a cookie). Old records are cleared out periodically. 

I've used the JSON trick before on other systems and it works well for archiving, but it does make building views from it a bit of a pain. I was hoping to use objects so that the email confirmation and views in the back office were easier to code, but I guess it's a small price to pay :)

- John

--