Entity Framework Code First - Database schema for a catalog with product and product options

Question

I'm trying to create a e-commerce website with out using any third party components.

My biggest problem so far is designing my model/database schema.

The e-commerce solution is for a Take away.

They only really have two types of Meals they Sell.

1. Rice Meals
2. Noodle meals Meals

Now Rice Meals have a set of options, so for example a Rice meal comes with either beans or plantain or both. (If both we need to off set the price)

Rice meals also come with a sauce the customer has 3 different options. There is no price difference.

Noodle meals

You can choose a Noodle type You Can choose a sauce that goes with it. You can choose if you want fish or meat

Then they have other products that don't have any options.

So my question is how can I create a flexible schema to store Products the options they have and the possible values for those options.

I also need to work out how to store what has actually been selected by the user.

I'm using EF with code first, would love someone to give me a few tips in the right direction.

The closest thing I have come across that may be a solution is this.

http://villyblog.blogspot.co.uk/2008/11/sample-database-schema-for-catalog-with.html

Really confused about the best way to do this.

Answer 1

Keep it simple!

Modeling is a skill. It's about observing and filtering. Even in a relatively simple business like a Take-away there is a lot of noise and if you manage to filter the noise and keep the essence your entity model will become both robust and flexible. First focus on the absolute minimum. Let me try to show you how this could work in your case.

The filtering begins with finding the "ubiquitous" language (Evans, Domain Driven Design): the "things" the business talks about and that are candidates to become entities in the model.

You talk about meals, types, values, prices, discounts, options, products. What are candidate entities?

One important step to take is to find the real, tangible "things". Customers don't eat options. They eat meals, or products. Nor do they eat prices.

"Option" is an interesting word. It is a covert verb. It's an act of opting for some "thing". It's a common design flaw in modeling to turn actions into entities, while they should become methods working on entities. Finding these disguised verbs is very very important. Without diving too deep into this issue I can say that having actions as entities make it hard to assign the right responsibilities to classes.

Likewise, prices (values) and types are no tangible things. They are attributes of things. Turning attributes into entities is a less obvious error, but it happens. I think the model you show as example contains both of the above flaws.

So far, in fact, the only real "thing" that emerges is a Product. The rest is either action or attribute. A Product can either be a meal, or a component of a meal. So these products come in combinations, or aggregates, which can be modeled by a hierarchy.

So here's the core of your "flexible schema to store Products":

You can store all possible combinations of products in one database table. No need to store options separately. Options are products as well. It's an act of combining to design the options in a hierarchy of products.

A concrete part of the hierarchy, the rice meals, could look like this:

The business does the combining, which is designing the hierarchy. The customer does the picking of options. Here business rules come into play. Let's say one rule is that the owner can combine any products, another rule is the customer can only combine end points (the smaller gray rectangles). The parent product could contain a property telling how many of its children can be chosen.

There may be a way to build these rules into the model, but coded rules are far more easy to modify than a model.. Let the model just be a dumb bag of data.

Now the part

I also need to work out how to store what has actually been selected by the user.

When a customer picks options he is making a classical order with order lines. That would make for a model like

Well, this is getting a long answer. A short word on the discounts. It depends a bit on how you want to calculate them. A simple way is a product property that's simply a multiplication factor to apply to the prices of each child product when more than 1 are selected.

Answer 2

Something like this might work, based vaguely on the link you provided:

MealType
- MealTypeID (short maybe? identity, PK)
- Name

Meal
- MealID (long, identity, PK)
- MealTypeID (FK)
- Name
- BasePrice
- IsActive (bit)

MealOption
- MealOptionID (PK) (short or int, identity)
- Name
- PriceOffset
- IsActive (bit)

MealMealOption (not the best name, but just represents a relationship between Meals and MealOptions)
- MealMealOptionID (PK, int or long, identity)
(composite foreign key with MealID and MealOptionID)
- MealID
- MealOptionID

Order
- (this holds stuff common to all orders such as billing address info, messages from the customer, etc.)
- OrderID (long, identity, PK)
- TotalCost
- TotalPriceOffset
etc...

OrderItems
- OrderItemsID (long, identity, PK)
- OrderId (FK)
- MealID (FK)
other order item-specific stuff...

OrderOptions
- OrderOptionID (long, identity, PK)
- OrderItemsID (FK)
- OrderID (FK)
- MealMealOptionID (FK)
anything else needed here...

Any table obviously will also have whatever other fields you deem necessary for that table.

Answer 3

The answer to this question is here >

Database design for user settings

It's a edr diagram of how to store: N number of settings, that are associated with N Number of users, and each user can have a N number of settings associated with that individual user. So you could have one user with 5 settings and another user with 10 settings.

This is very flexible and I'll be using it in the future. I have swapped the entity user and replaced it with product.

What I want to know now is HOW DO YOU STORE SELECTED SETTINGS? These tables are only able to store and show user settings and available options/settings.

Any ideas?