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.
Related
So, lets say I have 3 tables.
First table is the product table where it consists of
Prod_code, Prod_name, Prod_qty, Prod_Price1, Prod_Price2.
The second table is the Order table where it consists of
Order_ID, Order_Date, Total_price.
And the last table is the order detail table which consists of
Order_Detail_ID, Order_ID (foreign key from order table), Prod_code(foreign key from Product table), Qty_Ordered, and Price
If you can see I have 2 prices for each product in the product table for the purpose of:
If the Qty_ordered from the order detail table is greater than 10 unit, then the Price column in the order detail given will be Prod_price2
If the Qty_ordered from the order detail table is equal to or less than 10 unit, then Price column in the order detail given will be Prod_price1
How can I make this happen so when I create an order detail form, it can automatically give me the Product price based on the Qty_ordered that I input?
I believe this could require some if statements in the query but I'm a novice in Ms. Access and I need you guys' help. Thanks a lot
In a query that joins Orders and Products to OrderDetails, calculate a field with:
IIf(Qty_Ordered <= 10, Prod_Price1, Prod_Price2)
If you need to display this on data entry form bound to OrderDetails, build a combobox that lists products and has both prices as columns (can be hidden if you want). An expression in textbox can reference columns of combobox by their index. So if Price1 is in third column its index is 2.
=IIf(Qty_Ordered <= 10, Me.cbxProduct.Column(2), Me.cbxProduct.Column(3))
Saving this calculated result will require code (macro or VBA) in some event, probably form BeforeUpdate.
Me!Price = Me.tbxPrice
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.
there is a website which used to sale physical products ... now they want to sale some king of service which is completely different .... like credit packages to charge user account(to buy products) or buy sms .. stuff like that
so db used to look like this
order : user_id ,date , total_price
order_items : order_id , item_id , quantity , price
invoice : order_id , price , settled
Invoice_transactions : invoice_id , amount , date
basically invoice belongs to orders
now they want to sale services , so we have to create 2 orders table
product_orders (it used to be orders)
service_orders
now i have to choose a design for invoice table
i can add add another field to indicate type pf the order
invoice : order_id , order_type , amount
1 , product , 10000
1 , service , 10000
which somehow doesn't feel right ... or i can add invoice id to orders
invoice : order_type , amount , date
product_orders : invoice_id , date , total_price
service_orders : invoice_id , service_id , date , total_price
which one(if any) seems to be more reasonable design ?
here is products table :
here is what service tables would look like :
here is orders (which should change to product order )
here is what service_order would look like
I presume that both product orders and service orders have more in common than they have in difference. Within the greater business and financial ecosystem, they likely share the same roles/functions. So my first instinct to have a single table for both kinds of orders.
One-To-One tables
Another route is to have simply one order_ table, with a column indicating which type of order named something like order_type_ containing values like sales or products.
Move all the product-related columns to a separate child table, product_info_. Move all the sales-related columns to a separate child table, service_info_. I would make order_ table the parent to both, though technically we have a One-To-One relationship. For any given order_ row we have exactly one product_info_ row or exactly one service_info_ row.
This might minimize duplication of data in the database and coding in your app. Your app code uses the flag field order_type_ to query one or the other child table appropriately when you need the product or service details.
The invoices table links against the orders table. I assume invoicing works pretty much the same for both types of orders.
All fields in Order
Another alternative is simply including all the product and service fields within the order_ table. Simply ignore the product-related fields for the service orders, and ignore the service-related fields for the product orders. Not the most elegant, but if you have relatively few fields, and perhaps prefix the column names with prod_ and serv_, this may be practicable. I have certainly done this more than once.
It all depends on what you want to achieve with it, can a customer buy both in one order? The most common is what you did with invoice with an order_type it will have the least duplication
This is what I would try to do:
Table types
type_id | name
1 | product
2 | service
Table items would have common columns for both - products and services.
items: item_id, type_id FK(types.type_id), price, title, ...
Tables products and services with FK item_id and columns that are not common for both types (like products.weight).
Add type_id column to the orders table:
order : user_id, date, total_price, type_id FK(types.type_id)
Add type_id column to the table order_items:
order_items: order_id, item_id, type_id, quantity, price
The FKs would be:
(order_id, type_id) -> orders(order_id, type_id)
(item_id, type_id) -> items(item_id, type_id)
With those FKs it's not possible to mix different types in one order.
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;
I have a 'customers' table. Each record contains a customer name, email, address, etc.
I have an 'skus' table. Each record contains the name of an SKU. e.g. "Super Software Bundle".
An SKU represents a purchaseable item at a single price point. The purchased item can include one or more products.
e.g. The SKU record named "Super Software Bundle" may represent two products: product1 and product2.
For usability/ease reasons, other tables need to keep track of not only skus purchased, but the individual products a customer may have access to.
Question: how should I represent the variable sized nature of the SKUs in the database, where an SKU can represent from 1 to n products? Thanks for any help.
You will need a third table, that manages the relation between SKU and products, as a product may be part of more than one SKU (I guess). You have to model a m:n-relation.
product
id
name
price
...
sku
id
name
price
...
sku_product
id
sku_id
product_id
If I'm reading this right, you'll need a SKU table and a products table, and the products table will have a foriegn key to the SKU table.