I have a database for multi shop. Shop has many items like dress, food, cosmetics etc.
So for every type of item their is a table for store details like.
Dress: id, name, size, price, color, item_id
Food: id, name, type, price, exipry date, item_id
Cosmetic: id, type, price, gender, item_id
Item: id, tag, store_id
Store: id, name
Here item has OneToOne relation with Dress, Food, Cosmetic etc.
Store has OneToMany relation with item.
Now I want to fetch only item like Dress and Food only for a store. But don't understand how to query.
Now I am thinking to store a enum into item for tables like enum(Food, Cosmetic ...). Then fetch items by Dress with join Dress table and sperately fetch for food.
In their any way to change the database without this so that I can query better way. Is database design is bad that's why I am facing problem ? Any better way ?
I think that, if you can, you should simplify the data model.
Table: Store, containing the store id, name, address and any other information you need
Table: ItemType, containing item type id, item code, text description (basically a list of labels of types of items you can sell. Making this table instead of a new table for each type will make it easier on you when the stores add a new item type later
Table: Item, containing the a primary key id and the following foreign keys (store id, item type id), and then all your standard information. Price, name of the item, description
Then if you want to get items for one store, you select * from Item where store_id in (select id from Store where name = 'MyStore').
If you want to get all of the cosmetics from one store, it's select * from Item where store_id in (select id from Store where name = 'MyStore') and itemType_id in (select id from ItemType where code = 'cosmetics')
This will make maintenance a lot easier in the future when the item catalog changes, since it means you only need to add a row to ItemType before you can add new items. Same thing if you add a new store.
Related
I am helping someone build a grocery deliver service. Very simple site and order process. The problem I am having is knowing how to come up with schema for the orders. The order would have contact information, but would also need to have all of the products they ordered. Since it can/will be different for each persons order, how would I go about designing this? Would I just have a products ordered field with a string list of all the items? Or would I need multiple linked tables?
Thanks!
You need three tables:
a) Products - Contains the product details
b) Orders - Contains the order header, contact information etc
c) Product_Orders - is a table with two columns: product_id and order_id, that bind the orders to the products, and a quantity field and unit price.
You could have a customers table, but ideally information like the delivery address, etc, would be attached to the order so that if the user changes his address it will not affect your order history.
For the same reason unit price must be in Product_Orders, so that if a product price changes it does not affect previous orders.
Product table
with name and price of all products.
Customer table
with name, address, phone etc...
Order table
with entries for each order: order id, cusomer id, date etc
Order Items table
with all ordered items, with link to id in ordertable, product table, quantity, price, etc...
I have different tables with customer Id, items bought with a date of purchase.
books table consists of customer id, bookNr and date of purchase.
shoes table consists of custoemr id, shoeNr and date of purchase.
.
.
we have like for every item a table.
If the customer buys an Item(x) lets say a book with bookNr someNumber. I would like to retrieve all the orders in all the tables before the date of purchase of bookNr someNumber for all the customers.
Any suggestions how to design the query and the best way to represent the data.
The way you designed the tables mixes two concepts (type of item that got purchased and the purchase itself). This leads to the difficulties you now face.
An alternative approach would be to have a PURCHASES table that links to an "item" table. In the "item" table you could differentiate what item it is and, depending on how different the items are, link to further detail tables, that are specific to the item type.
This could be a DB design that looks like this:
[PURCHASES] -- [ITEMS] -- [BOOK_ITEM_DETAILS]
|
+-------[SHOE_ITEM_DETAILS]
If you want to keep your current design, the probably easiest approach here would be to create a view that combines (unions) the different item tables.
E.g.
CREATE view CUSTOMER_PURCHASES as
SELECT customer_id, shoe_Nr as item_nr, date_of_purchase FROM shoes
UNION ALL
SELECT customer_id, book_Nr as item_nr, date_of_purchase FROM books
...
That way, all purchases are available in a single view.
Now, if you look for all items purchased by a user before that same user bought a specific item (e.g. a shoe), you can use a join query.
SELECT customer_id, item_nr, date_of_purchase
FROM customer_purchases cp
left outer join
(SELECT customer_id, item_nr, date_of_purchase
FROM customer_purchases
where item_nr = <shoe_item_nr>
and date_of_purchase = <date_of_purchase>
and customer_id = <customer_id>) as ref_purchase
on
cp.customer_id = ref_purchase.customer_id
and cp.date_of_purchase < ref_purchase.date_of_purchase;
I have two parent child tables and a couple of supporting tables. I am struggling to figure out the right relationships between them.
Orders, a table that holds a list of Orders including:Order Id, Supplier, Order Date etc..
OrderDetails, a Table holds a list of products that have been ordered, and is a child of Orders, linked on OrderId. Key fields are the ProductId and the Quantity Ordered. Each order containes one or many OrderDetails that outline the products and quantities being ordered.
Shipments, a table that holds a list of Shipments, including Tracking Number and Shipper. Links to Orders through Order Id. An Order may have multiple shipments. For example, I ordered 100 lightbulbs. They were dispatched in 5 shipments.
ShipmentDetails, holds a list of product and shipped quantities and is linked to the Shipments table by ShippingId. Each Shipment may have multiple ShipmentDetails. i.e. One shipment may have 30 Lightbulbs and 10 Door Knobs.
Products is a table that holds a list of Products that need to be both ordered and shipped.
So the logic is that I enter details about the products that are to be ordered in Products. For example, 100 CREE LED Lightbulbs, and 50 Door Handles.
When I place an order, I create an Order in Orders.
i.e. amazon.com, order #45454.
Then I add child rows to that order in OrderDetails. i.e. 30 CREE LED Lightbulbs.
When the order Ships, I create an entry in the Shipments table. i.e. Tracking #46464646464, linked to OrderId in Orders. And then I enter what is in that shipment in ShipmentDetails. For example, only 20 or the 30 CREE LED Lightbulbs may be associated with this Shipping entry.
I am struggling with figuring out how to relate the Shipping Detail records to the Order Detail Table. Lets say the Shipping Detail Table has 4 fields.
ShippingID - a link to the Shipments table parent.
TrackingNum - a field that holds a tracking number.
Product - this should be a drop down, that says, the shipment I belong to is related to a defined Order (because ShipmentDetail is a child of a Shipment record which in turn holds a key to the Orders table, which in turn has OrderDetails that reference products).
Quantity - this should have a default (overridable) value that is the "Quantity Ordered" number from the OrdersDetail record that matches the Order Id and Product Id. Where OrderId is in the Shipments table (linked to the Orders table) and ProductID comes from #3 above. The reason it must be overridable is that a shipment may be a partial shipment.
I am stuck with the preceding #3 and #4. I hope I have explained this in a vaguely understandable way! The pictures below may help!
The ask:
What is the correct join between the ShipmentDetails and the OrderDetail Table
How do I create a field in the ShipmentDetail table with a default value pulled from the Quantities Field of the OrderDetail table, where
Shipments!OrderId = Orders!Id and ShipmentDetail!ProductID = OrderDetails!Product ID
I am working in MS Access 2016 - but I suspect this is a fairly generic SQL question...rather than MS Access specific.
I think the naming is confusing.
What I would rather have is (each first id is autoincrement, forgot how to say this on access):
// Product doesn't contain any information about quantity/price etc ...
create table Products(product_id int, name text, description text ...);
// Orders:
create table Orders(order_id int, client_name text, description text ...);
create table OrderDetails(order_detail_id int, order_id int, product_id int, quantity double, unit_price double, ...);
// Shipments
create table Shipments(shipment_id int, company text, description text ...);
create table ShipmentDetails(shipment_detail_id int, shipment_id int, product_id int, quantity double, price double default 0, ...);
// inserting shipments per product (defaulting to total quantity per product), assuming we have shipment_id SID
insert into ShipmentDetails(shipment_id, order_id, product_id, quantity)
select SID, order_id, product_id, SUM(quantity)
from OrderDetails
group by order_id, product_id;
Then you can of course have some filters (date, customer etc ...).
For the first question, I am not clear what exaclty you want to return.
Here is a comparison of quantities:
select t.order_id, t.product_id, sum(t.quantity) as product_quantity, sum(u.quantity) as shipment_quantity
from OrderDetails t inner join ShipmentDetails u
on t.order_id = u.order_id and t.product_id = u.product_id;
I want to make a simple database to order products, like chips/drinks (as full product, without any specific info about product just name and price for unit)
I designed this but I'm not sure if it's good:
**Person:**
id
username
name
password
phone
email
street
zip
**order:**
id
person_id
product_id
date
quantity (neccessary?)
status (done or not)
**product:**
id
name
price
relations:
[person] 1 --- 1 [order] 1 --- many [product]
(I'm not sure about relations and fields)
It seems that in your way you are going to end up in orders containing a single product (even if you use the quantity)
I would modify the Order table:
**order:**
id
person_id
date
status (done or not)
And I would add a new table:
**OrderDetails**
id
order_id
product_id
quantity
You may check out for db normalization. You should add columns to a table that are directly related to the table. For instance date in the order is valid, because it refers to the order it was made. On the other hand it wouldn't be valid in the person table (unless it was referring to the person join date). So, similarly the quantity refers to the product in the order (thus in OrderDetails) not in the Order or the Product.
You will probably need an intermediate table between order and product, so you can add many times same order to different products
I am building a database which consists of a
table of category, customer table, and table of product which fetches information from categories.
Now I need a new table for sale which consists of customerID, date, productID. My problem is
the customer may buy many products. how can I make the relation between them in SQL Server 2008?
Customer {id, name, ...}
Product {id, name, ...}
Sale {product_id, customer_id, order_id, qty, ...}
Order {id, date, ...}
Just add a order table, the order table will keep reference to the products in the order.
Your drawing commented on in #orn's answer only makes sense if each sale can only involve one product.
Mr Fliim put you on the right track to deal with multiple products in one sale.