Store Shopping Basket in Java as Blob in Database...or not?

So I'm working on a shopping basket application that requires a persistent basket and am trying to decide whether to store my basket/items as a blob in the database or break them out into multiple tables (*e.g. - tbl_basket, tbl_basket_开发者_JAVA百科items, tbl_basket_item_variants*). I have no need for sorting or filtering of basket items. I will simply query the basket based on soldto (btw, there could be multiple baskets per soldto). Baskets will only be valid for a relatively short period of time (6-12 months max). They could have several hundred line items (rare case), but I don't expect anything really all that big that it would degrade performance. The number of users is relatively small...400 concurrent users max. Typical usage would be somewhere around 50-100 concurrent users.

I'm leaning towards simply storing my basket as a blob simply because it's simple and relatively clean (yes I'm lazy). My question is, am I missing something? What are the drawbacks to this approach. What are the benefits? The one drawback that comes to mind is if my Basket object changes, it could be a problem for active baskets.

Thanks for any insight you might have.

---

use a basket, basket_item table pattern, and leave blobs for database opaque data like images, documents, etc.. Eventually you will want to tie basket items to inventory control, or analytics, or...., and having that data in a blob will kill performance.

---

Don't store in a blob. Because you don't need to sort or filter today doesn't mean you won't tomorrow or next week or next month. Also, you'll be protecting yourself much better against change; using a blob means extra work converting to new formats as needs change.

Doing it the correct way now will save you tons of work in the future.

---

There is nothing inherently wrong with doing what you want to do here. You are basically storing a hash table (or an object, or a property list) encoded as binary data and retrievable by a single key. It will make it harder to query by other fields of course, but if you are sure you don't need that then go ahead.

The solution you are proposing is basically why some people prefer "object databases" to relational ones. They make it very easy to store objects!

---

Using a blob is bad idea from various points of view

1. Blobs are slow, de/serializing your shopping cart is going to be very slow and you'll probably have to do it on every page view per customer (in order to display item count, or a full mini widget with the cart contents)
2. Future-proofing, I know we should not over engineer our solutions and try to keep the YAGNI principle in mind always, but I guaranty you that eventually the business will want to do stuff with your saved carts, like analysis of abandoned carts, items that get added to carts most often, average cart value, average item quantity per cart, etc. etc. etc.,

You'd be shooting yourself on the foot if you use blobs and setting yourself up for a lengthy (probably painful) re-design later on.

---

You better don't have a "smart column" in your database. They are supposed to be just data, this is what database for.

Smart column is some column which need further processing to make use of it, e.g.: A1234 => A represent male, and 1234 is the serial number. Not to mention your "blob" shopping cart, which is way "smarter" than the example before.

refer to http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533