now i'm developing an e-commerce system.
I've table named cart which store the cart_id, product & price.
Now, I want to proceed with the checkout. When the customer click checkout button, all the items in cart will become 1 order. But I have no ides how the order table will look like? because in 1 order may got many cart_id.
anyone got idea for this table? from cart to checkout.
By what I have understand,
you can have several product in one cart
you can have several cart in one order
Am I right?
If this is the case, the best way I think would be to create 3 tables, with one-to-many relationship between the tables:
Related
I have three tables: items, sold, and invoice. The item table tracks individual item prices and descriptions, the sold table tracks items the belonging to a particular invoice, and Invoice tracks the date and other information. Invoice has a one-to-many relationship with sold and sold has a one-to-many relationship with items.
Here are the relevant columns in my tables: invoice(invoiceID, total) sold(soldID, invoiceID, itemID) item(itemID, description, price)
I currently have no way to track the total price for the invoice without manually summing the items. The total column in invoice must be manually inserted.
I'm looking to create a trigger the finds all the rows i sold that have a matching foreign key for invoiceID, then adds the prices of the relevant items and outputs that to invoice.
If this is not possible, I could also add a new price column to sold, then use multiple triggers to eventually work my way up to invoice.
I'm not in a position where I can make any significant changes to the structure of the database, so if possible it'd be best to keep the fields and relationships as is.
If anyone has any input on how to create this trigger it'll be greatly appreciated.
#stickybit is exactly right. You don't want redundant data. You should not put any sort of derived total in an invoice record. Instead you should get it with a query or a view.
It's sometimes hard for people new to using SQL to believe, but queries and views are typically just as quick for retrieving aggregates like totals.
Views and tables look precisely the same from the perspective of application software. So make a view of your invoices that shows the totals. Something like this.
CREATE OR REPLACE VIEW invoice_with_totals AS
SELECT sold.invoiceId, SUM(price) total
FROM sold
JOIN item ON sold.itemID = item.itemID
GROUP BY invoiceID
Believe it or not, doing things this way with views will save you (or the people who will use your application) all kinds of troubleshooting craziness in the future. If you do things this way, there's simply no possibility of your totals disagreeing with the details in your invoices. If you use a trigger, that's not guaranteed. And, you know, Murphy's law, big customer, incorrect invoice, you get the picture ....
I have hard-won experience backing up my suggestion. I suspect #stickybit does too. Please consider it.
Okay, my partners and myself created these a while ago. We are going to be transferring this into SQL through Visual Basic soon, but I want to make sure everything is ready to go. Two major complaints that we were not able to fix was...
"By having Transaction and Product directly connected you are unable to allow multiple products on the same order (customer can't order both a latte and cappuccino on the same order)."
"Membership table: Not sure what the data in DiscountTypeTotal means - do you have multiple pieces of data in the same field? (then your table isn't on 1NF).
It looks like you need to allow each member to have multiple discounts - so you need another table to capture that."
How do we effectively correct these? How else would we connect Transaction with Products? I understand that the customer can only purchase one item per transactions, so would we have products and another table for multiple items? Allowing multiple customers to have discounts, I am lost. Any help would be appreciated.
I have designed an ERD for a website I am about to build.
This website has 2 groups: the USER and the COMPANY. Different companies (or shops, to be precise) have the option of logging into the site and enter new products into the system. The users can then log in and view products based on brands and categories.
In the ERD I have created all the tables, fields and one-to-many relations to the best of my knowlegde. I think that went well until the category tables.
I want the products to be categorized in like "MEN&SHOES", "KIDS&CLOTHES". I figured out I am going to need 2 tables for that: CategoryPersonGroup & CategoryProductGroup. But I do not know what is the right approach to link this to the products table. Please help! This is my ERD:
I think many to 1 relations between product and category tables would be convenient such as:
Product (N) -- has -- (1) CategoryProductGroup
Product (N) -- has -- (1) CategoryPersonGroup.
You can use inheritance approach to this matter, i.e. make category table to store any values that are common to all the articles, and then make separate tables that will inherit category table, in which you can store your own values for that tables. And that's it, just link the main category table to persons and voila.
I am building a shopping cart in CakePHP and currently have the following relationships:
Product HABTM (HasAndBelongsToMany) Options
Cart HABTM Products
Pretty standard? I'm just not sure what to do when a user selects some options for the product and saves it to the cart. Do I add a new model called CollectionsProductOptions?
What's the best way to store this kind of data? Should I just serialize an array of selected options and save to the carts_products table?
My approach was to try to stick to convention. I have a cart model, an item model, an option model and a value model (an option can have multiple values). Once I got it to there, everything fell in to place. You need to set recursion to "3" but when you read the cart, you get everything perfectly laid out.
I keep my cart products/options separate from my catalog products/options. On the cart side, an option only belongs to one product. On the catalog side, an option can belong to many products. Your approach may be different. I do this because options may change and I don't want my old sales information to change. I do this for all cart tables. The cart_products table is different than the products table. The product_options table is different than the options table, etc.
Suppose i have tables
Products -------product_id , name , price , size
shopping_cart------cart_id,item_id,user_id,quantity
order----order_id , user_id ,totalprice , date
orderHistory---------user_id , item_id,date,order_id
I am confused how should i store shopping history because if i store item_id , then there may be the possibility that some product may be deleted , then what should i display in history.
There is possibility that price , size , other dimension of that product changes with time but in history i don't want to change
so how should i design the database
For the product deletion issue, try including something like an "Active" (boolean) field in the product table. This way you don't need to physically delete products, just deactivate them. Then you can build your code so that inactive products don't show in the catalogue, but they are still available in your database to show in the order history section.
I'm guessing you're trying to create something like an "OrderLine" table with your OrderHistory table. You should only need to link this to products, and your order header (Order) tables, you don't need to link it to users as the order header table is already linked to a user. If you add some additional fields like "quantity" and "price" to the OrderLine table then you can create a snapshot when the order is placed, and insert the price (at the time it was ordered) and the quantity ordered into you order history table. This way if the product price is changed over time, the information in the OrderLine table remains the same and you still have the original price.
You could still build some entities for save product history (price etc) if you wanted to hold this to show price trends, but in terms of maintaining your actual order information its not necessary.
This approach means your shopping cart table could used as a "work in progress" repository where you are only storing current carts, and once the order is completed the cart is emptied and the data inserted into your order header and order line tables.
This doesn't cover everything, but hopefully gives you some ideas on approaches you could take in regards to your questions.
I face the same problem right now, and I am solving it basically by duplicating the relevant data into a secondary table, that the order history models can look at. They will never change, and never be deleted.
This way, if prices change or titles change, you'll have a snapshot in time of the order.
Another way would be to create versioned products, and store the specific version id. When the product changes, the displayed version updates to the newest product ID.
You are duplication history either way.
In my opinion you should have a table between order and product in which you can store the information of order and product. you can use order history table for this purpose. Just store the at time of shopping information in that table. It should be a good practice to do in my opinion.
Even if the actual values changes in product table you dont need to change the values in order history table. Just touch that table only at the time when user do some kind of shopping otherwise you dont need to do.
I also suggest you to create a customer table and store customer information in that table and use also customer id in orderhistory table also. It will help you to classify the history even with respect to customer