Reputation: 1928
In my e-commence app (for café/restaurants) I currently have the following database structure.
The cart is the shopping cart, in which you can add products, a temporary place before the products/an order is sent to the server. The ProductCart
is a line item, many products (could be the same) with the different quantities, sizes, frying levels etc. When a order is sent, the cart is cleared and the products in the cart is transfered to the ProductOrder
entity (an Order
).
I now want to extend this further, with the ability of the products having ingredients and this is where it gets tricky and too complex for my head and database skills :-). As well as the (same) products can have different sizes and frying levels (hence the line item) a product should have the ability to have many different ingredients (add ons) for example a pizza, where you could choose the topping. This is what I have tried so far:
But I am not sure if this is the right structure or way to do it?
Upvotes: 1
Views: 1409
Reputation: 80273
There is something fundamental you have not grasped about Core Data. Your ProductOrder
entity is essentially a join table. This is completely unnecessary if you are not tracking additional attributes in this table.
Instead, you should have a many-to-many relationship between Order
and Product
.
It might seem that ProductCart
satisfies my condition above that in this case a join table makes sense. But no - you should simply add the orders to your cart and track all the information in the Order
entity.
Upvotes: 1
Reputation: 33428
This is my suggestion.
Remove ProductOrder
and Order
entities. They are the same as ProductCart
and Cart
.
Now ProductCart
should have an attribute like synchronized
that is 1
or 0
based if it has been sent to server or not.
Through this you should simplify a lot your model. About Ingredient…
entities they seem ok to me.
Upvotes: 1