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.
Related
Table1 feildes
Product{ID,Product,Quantity(in peices),Cost(per peice)}
table2
Customer{ID, Name, Type(local,sale's man)}
table 3
customer order{ID, date,customer*, product*,quntity,price}
here customer is coming from table 2 named as customer while product is coming from table1 named as products
i just want to show remaining items in order table. any can help me to make this happen?enter image description here
You mean you want to know how much of each product remains after filling orders? This is calculating inventory balance - a common topic. You need a table that records receipt of product, which is apparently your Products table but I think would be better titled ProductReceived. Do an aggregate query on ProductReceived and an aggregate query on Orders then do another query that joins the two and subtracts the latter from the former. Customer table not needed for this. Products table would just be a lookup table for product info - no Quantity or Cost fields as these belong in ProductReceived. Products table should have the selling price you want to charge.
You have misspelled 'piece' in your field names.
Advise no spaces, punctuation, or special characters in field names (underscore is only exception). Better would be Qty_Pieces.
A company has many products. It has many stores. Each store has different price and inventory to track.
My current DB Design is:
Products
ID product_name price inventory
Stores
ID store_name
ProductAttr
store_id product_id price inventory
Now I am saving the inventory and price in product table itself in case a new product is added in one of the stores and the ProductAttr table row is not created for other stores, in which case they can default to products table.
Is it better to have the attributes move to ProductAttr table completely. If they add a new store in few weeks time, I need to make sure all product attributes are created under this new store. Also when a store creates a product, to create rows for all the stores.
What would be the best approach to tackle this kind of situation?
You are thinking along the correct line. The inventory attribute should belong to ProductAttr as its a property related to that store's product.
You can futher add a default store, which can be assigned in case you don't have stores to assign.
The total product inventory will be the sum of inventory in ProductAttr table.
I want to store a list of Sellers, who sell a certain Category of products each, and then, each Seller will have Products from these Categories.
What is the best way to design this? Currently, what I have is three tables, Seller, Category and Product designed in this way.
How do I link Seller and Category? I feel like I am creating too many relationships here.
One way would be to create a separate table with indices for SellerId and CategoryId. Also, I think I will need a separate table for SellerId and ProductId too. Is there a better way to approach this design?
1 seller can have multiple categories,
1 category can have multiple sellers,
1 category can have multiple products,
1 product can again, have multiple sellers,
1 product can have only 1 category,
and last,
1 seller can have multiple products.
Based on your update, consider this structure...
Seller
----------
ID
etc.
Product
----------
ID
CategoryID
etc.
SellerProduct
----------
SellerID
ProductID
Category
----------
ID
etc.
In this case:
Seller and Product are aggregate roots
A Seller can be linked to multiple Products
A Product can be linked to multiple Sellers
Category is an attribute of a Product
Sellers are "linked" to Categories implicitly by the Products they sell
Would a Seller ever need to be linked to a Category for which that Seller has no Products? If not, this structure should do the trick. If a Seller needs to be linked to another Category, that Seller simply needs to link to a Product of that Category.
By demoting Category to a value type instead of its own entity, you don't need to link other entities to it.
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'm creating a coupon system with many different types of coupons. I'd like to structure it so it can be extended. I'm not sure the best way to store the different types of coupons, for example:
Fixed amount off entire order
Fixed precentage off entire order
Fixed amount off one item (could be by sku of item or could be most expensive item)
Fixed percent off one item (could be by sku of item or could be most expensive item)
Buy x get y
Free product (by sku of item, by price)
x for $y (3 for $2, 10 for $15, etc.)
I'm using mysql, would it best to store as an array? json? Any other ideas or people with similar issues care to share how they did it?
Off of the top of my head you could have tables designed as follows:
Table: Coupon_Summary
Columns: Coupon_ID(primary key), Coupon_Name
This table will hold 'top-level' data about the Coupon.
Table: Coupon_Description
Columns: Coupon_ID(foreign key), Coupon_Description
This table will hold the description of the coupon.
Table: Coupon_Value
Columns: Coupon_ID(foreign key), Coupon_Value, Coupon_Currancy
This table will hold how much discount the coupon offers. Coupon_Value can be a percentage or a hard value(percentage will be appended with a % sign), if this is zero the coupon offers full discount, or the item is free in other words. This also includes the currency to base the discount amount off of, so that you can do conversions between currencies.
Table: Coupon_Target_Order
Columns: Coupon_ID(foreign key), Order_IDs
This table holds data related to which Order the coupon effects. If the Order_ID is null or zero, the coupon is valid for all orders. Otherwise you can have multiple IDs for multiple orders.
I hope this was of some help =).
I would create another table - tblCouponType for instance and populate it with a unique numerical and string for notes of the types I have, and add to it as new types become available. Then add another column to your coupon table that references the numerical value of your coupon type. This helps with the whole -"Relational" part of the database:)
I assume you have some sort of products table that contains all products you can sell. You can create a coupons table that looks something like:
id discount discount_percentage
INT PK DECIMAL(10,2) DECIMAL(3,2)
1 5.00 NULL
2 NULL 10.00
Then you could create a link table coupons_products like this:
coupon_id required_product_id
INT FK INT FK
1 4773
1 993
So in this example, coupon ID 1 gives a $5.00 discount and requires two products to be present on the order: 4773 and 993. Coupon ID 2 gives a 10% discount and requires no products.
With SomeSQL, I'd rather not use JSON for it is nearly impossible to efficiently query it.
My Approach would Be, simplistically speaking, to have one Table for Coupon types (columns: id, name, ...) and another one for The actual coupons.
In The coupon Table, I would have a column "type_id" Cross-referencing to The "couponTypes" Table (or a Foreign Key, for that matter).
This way, you can always add new Coupon types later on without invalidating The Data you had to this Point.
Querying "Coupons by Type" is a matter of
"SELECT 'id' FROM couponTypes WHERE 'name' = 'fixed sum'"; => $id
"SELECT * FROM coupons WHERE 'type_id' = $id"; => All fixed sum Coupons.
Welcome to MySQL!