design a database for a shopping-cart application? [closed]

孤街醉人 提交于 2019-12-02 18:30:26

There can be five tables in database:

CATEGORY this table stores information about products categories of your store and categories hierarchy.
parent field of this table stores ID of the parent category.

PRODUCT all products of your store are stored in this table. This table has a foreign key categoryID which identifies ID of the category to which a product belongs.

ORDER this table stores information about all orders made by visitors of your store.

ORDERED_SHOPPING_CART table is tightly connected with PRODUCT and ORDER tables; stores information on customers' orders content.

SPECIAL_OFFER table contains a list of products, which are shown on home page as special offers

A brief answer is the way that i would tackle this problem. Firstly, there are loads of open source or free, web based shopping carts. This means that you can get one, set up the database and then have a good look around what they did.

Ask yourself questions such as, why have they done that? Why is it good? What downside could there be? How would i do it differently? why?

I would try to procure a database design tool that allows you to visualize the database. (like database designer in visual studio or i have one from MicroOlap that does pgsql databases)

Then you need to think about what you need in the database. What is the customer going to do? Buy products! Therefore you need a products table. Without going down the whole route you can see the point. Imagine what is needed, then basically make a table for it.

If you have more than one option for a field in a table, make another table with a relation in it. So if you have a product table and you have a status field. you could have more than one status. (eg out of stock, limited number, big item, expensive) instead of hard coding these fields, make a table and allow the user to add items to the table. then in the product table add a field status_id and link it to the status table

Many - many relationships are useful things to know. (i fell short to this myself.) say you have a component and product tables. The products can be made up of lots of components and the components could be allocated to many products. Create a mediator table. Something like prodcomp( and in this you would have fields like id, prod_id, comp_id, qtyneeded).

Learn to index correctly.

Don't create the database until you have a solid idea of how it will work. this saves time in recreating it later.

There may be more to this, however, i hope i have given you a good start.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!