How are Magento orders mapped to the customer? Does the order contain the customer ID or does the customer contain all their order ids? Trying to figure out if changing order numbers will mess up customer mapping.
Let me answer your questions at first
How are Magento orders mapped to the customer?
Magento Orders are mapped to the customers using "customer_id" Foreign Key field in the order tables "sales_flat_order","sales_flat_order_grid","sales_flat_order_address". And Customer entity has no reference to the orders in turn.
Does the order contain the customer ID or does the customer contain all their order ids?
Order only contains the customer ID not the other way around. Basically Customer entity follows the EAV structure like products and categories.
Now coming to your task of changing Order Numbers (technical field name increment_id).
Yes you can change the increment numbers of the order. You need to do that in two tables
1. sales_flat_order
2. sales_flat_order_grid
Please make sure to reset the order increment last id of entity type id "5" which represents Order after completing your task of changing the order numbers. You should do this in the table "eav_entity_store"
Let me know if you need more information regarding this.
Related
Hi I am making a restaurant management system for an assignment and I have a customer table, item table and order table. I want to enter the customer ID and the item ID to the order table when a customer places an order. My question is how to handle this when one customer orders several items together, how can I insert this to the order table? Is there a way to enter the foreign key of multiple items to the item ID column of the order table?
I am using MySQL server 5.7, Java 1.8 and NetBeans 8.2
Thanks!
Entry in Order table should per user not per Item. And if you want to insert items their are two ways one is in Order table as meta with order entry and second is create another item table with order id as ref key.
You need two table. Order and Order Details.
Order Table will contain Order ID, Customer ID, Date, Total Price, Tax, Offer, Coupon and other details regarding order.
And Order Details will contain Order ID, Item IT, Price, Quantity, Discount, and other details regarding each order item.
How do I represent invoices into an MySQL table structure?
The invoice table has the following fields:
id
customer_id
services
tax
total_price
date
...
Now the services can contain one or more articles and, what makes it complicated, various prices. The actual price of a service is negotiated, there are seldom fixed prices because each customer has individual requirements. These items have to be listed on the invoice and the prices of each have to be listed and summarized + tax.
What is the best practice for this purpose? I want to make it normalized if possible, something more sophisticated than just saving an (serialized) array of service => price into the service field, if this is possible at all. Do I use a second table for each service + price and hold a list of IDs with foreign keys?
I think you should follow Has And Belongs To Many relationship. Fr that you use two more tables for this one is 'services' and other is 'invoice_services'
'services' table contain service info and its price etc.
'invoice_services' table will be the join table for 'invoice' and 'services' tables. 'invoice_services' table will contain 'service_id' and 'invoice_id'.
Then you can remove the column 'services' from 'invoice' table.
If you want to maintain negotiable price for each service, then you can add one more field 'custom_price' in 'invoice_services' table.
Then using joins you can fetch the relative data of any invoice.
Hope this may help :)
I'm designing a relational database tables for storing data about eCommerce scenario where I need to store
List of Products purchased by a user
List of users who purchased a particular product.
Its a many to many relationship.
So far I could only thinking of doing this.
create a table for storing orders
table recordorders(
userID // foreign key from users table
productID, // foreign key from products table
dateofpurchase,
quantity,
price_per_unit,
total_amount
)
It will act like a junction table.
Is this a good approach and are there any other methods than junction table that are more effective and efficient for querying ?
Your bullets describe two tables, not one. Your junction table is not properly described as two lists. It is a set of order info rows. The junction table you gave holds rows where "user [userID] purchased product [productID] on ...". Ie it records order info. (Combinations of user, product, date, etc of orders.) Given a user or product, you can get the corresponding bullet table by querying the order info table.
However your table probably needs another column that is a unique order id. Otherwise it cannot record that there are two orders that are alike in all those columns. (Eg if the same person buys the same product on the same date in the same quantity, price and total.) Ie its rows probably aren't 1:1 with orders. That's why above I called it an order info table rather than an order table. It records that some order had those properties; but it doesn't record distinct orders if there can be orders with the same info. It's really a many-to-many-to-etc (for every column) association. That is why an order id gets picked as a unique name for an order as further info. This new table would be called an entity table, not a junction or association table. It holds rows where "in order [id] user [user] purchased ...".
PS An order is usually something that can be characterized as an association on/among/between an order id, user, set of order-lines (product, quantity, price & total), and other stuff (date, grand total, etc). The orders are usually relationally characterized by an order entity table on order id with its user, date etc plus an order-line association table on order ids and their order-line info.
PPS It's time for you to read a book about information modeling and database design.
You don't "store" those two things in a table (Junction, or otherwise), you discover them from the raw ("Fact") data:
Using your proposed table:
List of Products purchased by a user:
SELECT productID
FROM recordorders
WHERE userID = 123;
List of users who purchased a particular product:
SELECT userID
FROM recordorders
WHERE productID = 987;
For a purchase-scenario:
I have a table (PRODUCTS) that contain columns like NAME, TYPE, DEFAULTPRICE, ID and a table with sales (SALES) that contain columns like DATE, ID, PRICE, AMOUNT where ID in SALES is a foreign key to primary key ID in PRODUCTS. Very simple, not much to mess up there.
This works fine as long as you insert one row of whichever product (and how many) at what total price.
BUT - let's say I want to design this system to support "basket"-kind of shopping. I.e. a user selects several items that are not the same product ID, but gets a single ORDER ID that contains all the products that were included in the order, the amount of each product, the total price, date etc.
How would one go about creating this? I was thinking maybe creating a table called "ORDERS" and link every row from SALES to an ID from ORDERS - but I'm not sure.
You would create a table called Orders for each order. It would have whatever information you want about the order.
You would then have a table for the products in each order. A common name is OrderLines. This would have an OrderId, linking it to the Orders table and a ProductId linking to the Products table.
I want to know how to design invoice table.
An invoice include many orders from order table.
Is this invoices table is correctly designed?
order
order_id (PK)
User_id (FK)
total_cost
order_date
status
order_item
order_item_id (PK)
order_id (FK)
item_name
cost
invoice table
invoice_id (PK)
invoice_no
invoice_date
period_start_date
period_end_date
status
invoice_order (an invoice with many orders)
invoice_order_id (PK)
invoice_id (FK)
order_id (FK)
Is invoice_order table necessarry?
I could add invoice_id (FK) field in the order_table instead. The "order. invoice_id" would be updated when I have added a row in the invoice table.
You only need the invoice_order table if:
An order can have one or more invoices
AND
An invoice can be linked to one or more orders
By your suggestion at the end of your question, that's the case. You should not just have invoice_id and get it updated when a new invoice comes in, because you would lose the link between the order and the previous invoice.
Update
By the way, it's good that you have cost and item_name in order items, which is something beginners tend to find weird. You have to have those for historical reasons and to make possible to reprint the order with the same data, say, 3 years later, when the item might have had its name slightly changed and cost has surely been updated.
You need the linking table. An order can be in mulitple invoices (if they didn't pay it!) and an invoice can contain many orders. In a linking table though I would not bother with •invoice_order_id (PK). The PK is a combination of the two FK fields. That guarantees uniqueness and since you are unlikely to have a child table of the link table, you really gain nothing by adding a surrogate key to it. Even if you did the performance difference between joining on two indexed int fields vice one would probably be negligible.
Most invoices will have:
Customer ID
Sales Rep ID
Payment Method
Ship to Address
Billing Address
CheckBox: Shipto same as billing
etc.
Generalisation !! You should consider reducing that to 2 tables: Documents and DocDetails. Just add a DocType field in the Documents table, to differentiate Orders from Invoices.
If you need to track backorders, add a Link field to your DocDetails.
When you add an Order detail line, give the Link field the value of the table PK (counter).
When you add an invoice detail line, give the link the same value as the related order detail.
By the way, did not see any CustomerId in your tables !