I'm implementing a price database where multiple sellers sell the same product at different prices. Each product is unique, and is identified by its model_number. Right now I have 1 seller in my price table. I am looking for the best way to build a table that can list multiple prices with each price being a field for a row whose primary key is model_number
The table looks like this:
model_number | seller | price
abc Store1 99.99
This structure works well when there is only 1 seller, as the primary key is model_number and my query to update the price uses on duplicate key update, which only updates the product if the price changes. Furthermore, the primary key is the model_number, but if I have multiple sellers that have the same model_number but with a different price, I believe when updating the table, the database will get confused as there will be duplicates of model_number.
Should I give each seller a unique key for their product? for instance, should seller_1 have a primary key of seller_1 and keep that value the same so the database knows to update if the price field of seller_1 changes.
Thanks
You can make the model_number and the seller primary key. That way you can have several tuples with the same model_number as long as the sellers differ.
model_number | seller | price
abc Store1 99.99
abc Store2 9.99
Is this what you want?
Three tables:
Seller, Seller_Product, Product
Each row of the linking table Seller_Product contains two Foreign Keys to corresponding Seller and Product row. The price is an attribute of the linking between a Seller and a Product. So it becomes a field in the linking table.
Seller: ID, Name, ...
Seller_Product: Seller_ID, Product_ID, price, availability, ...
Product: ID, Name, model_number, manufacturer, ...
This is a common table design for N:M Relationship.
So far your table structure looks good, all you would need to do is add the seller column as part of the primary key of the table. What you have here is a Many-to-Many relationship between products and sellers. That many to many relationship has some additional data, which is the price.
I think what you mean by "give each seller a unique key for their product" is actually what they call a surrogate key. You could give the table a primary key column so it looks like this
id | model_number | seller | price
Where id is the primary key of the table, and model_number and seller is are secondary keys and foreign keys, but that is really up to you, either way will work just fine.
Many to many relationships are what you are dealing with here.
You want three tables for this solution:
Products:
A table with products information, including a unique auto-incrementing id.
Sellers:
A table with sellers information, including a unique auto-incrementing id.
Products_To_Sellers:
A table with product_id, and seller_id ( INDEX these columns individually )
With this approach, you can JOIN the tables to view sellers products, but you ultimately have a SCHEMA that scales infinitely
[seller] [product_seller] [product]
-id seller.id -id -price
product.id
if you need products to be unique, you'll need another table:
[seller] [product_seller] [product] [seller_price]
-id seller.id -id product.id
product.id seller.id
-price
Related
My database is called 'shopping' and it contains the following tables:
products (product_id, product_name, price, category_id)
product_category (category_id, cagtegory_name)
customers (customer_id, username, pass, fname, lname, email)
orders (order_id, order_date, product_id, customer_id)
Now I want to consider keeping records of each products stock levels.
i.e
product_id = 1
product_name = MICROSOFT Limited Edition Gears 5 Xbox One X, Tekken 7 & Project Cars 2 Bundle
price = 449.99
category_id = 2
stock _id = 1 ( references stock_id in product_stock table ) :-/ ?
I have considered THREE approaches to storing 'stock info' on products.
Approach a) Add a new Column in products table called 'stock_level' simple, and valid since stock level is entirely dependent on its primary key in this situation.
Approach b) Create a new table called 'product_stock' , with the columns 'stock_id, and stock_level'.
The confusion is arising in the logic here.
For some reason, having gone with approach b, I had made the primary key of product_stock table (stock_id) ALSO a foreign key, referencing back to the products table as:
product_stock.stock_id = products.product_id
i.e
product_stock.stock_id 1 REFERENCES BACK TO products.product_id 1
product_stock.stock_id 2 REFERENCES BACK TO products.product_id 2
etc etc
THE THIRD approach I thought about was keep the stock_id key as a Primary Key only, and sever the link back to Products table. Then in products, create a column called stock_id with is a FK referencing stock_id in product_stock table.
Which of the three approaches seems the best ? I for some reason, regret deleting the columns and relations set up which was giving me behavior as discussed in approach b.
The reason I liked approach b was because, if you hover over each stock_id key in product_stock, you can see instantly what product it relates to in the products table ( phpmyadmin ).
thoughts on this folks ?
Refer to question and read.
no need, its all on phpmyadmin and not required in this case.
refer to question.
As far as you explained, each product has only and only one stock value. The simplest way to proceed is to to store that information directly in a products table: option a) in your question.
Using a separated table would be useful if, for example, you were in a situation where you have several stores and you need to keep track of the stock level of each product in each store. You would then create a separated table, with a column to store the id of the product, another to store the id of the store, and a third column to store the level of this particular product in this particular stock.
I have a table where I store products, and in the same table I store the ID of the category I want the product to be in.
My product table looks like this:
id | product_name | category_id | price
And then I have my category table:
id | category
My problem is to know how I can insert multiple categories into my category_id, and if it is possible.
If not, whats the best way that I could do it?
It is possible but you really don't want to go there. Storing multiple values in a single datarow column is a terrible idea in 99.99999% of the cases.
For more information, read Is storing a delimited list in a database column really that bad?, where you will see a lot of reasons why the answer to this question is Absolutely yes!
What you want to do is to add another table to store the relationship between the products and the categories. This is referred to as a many to many relationship.
This new table should hold the product id in one column and the category id in the other one, and have a composite primary key that is the combination of both these columns.
This way, you can have many products in the same category, and many categories for the same product.
You need a many to many relationship, which mean you need a third table let's call it ProductCategories, in this case you will have
Products
id | product_name | category_id | price
Category
id | category
ProductCategories
PruductID | CategoryID (combined PK)
I'm starting with MySQL database relashionships and I have a question.
I'm going to put in an exemple:
Table A = customer
Table B = products
Table C = sales
I wanna know how can I make a relationship with these tables where "sales" has only one customer and multiple produts.
The "sales" table can't have a Primary Key with both foreign keys, cuz it will have multiple products.
I could create a ´idsale´, but how I would structure the table to receive multiple products?
Thank you.
Costumers and Sales have a ONE-TO-MANY relation. You could add a customer reference on the Sales table
Table sales
- id PK
- customers_id FK
Sales and Product have a MANY-TO-MANY relation. You will need a new table to map this relation
Table sales_has_products
- sales_id FK
- products_id FK
I would recommend creating a fourth table, let's call it productSale, that has its own primary key, as well as foreign keys the sale ID and the product ID. Sale, then, will just have an ID and the foreign key of the customer ID (as well as any additional info you want, of course.)
This way, a sale can include multiple items of the same product (because all productSale rows have a unique ID), and all of the items included in a sale can be found by querying productSale by the specific sale ID.
I'm designing a database for an online checkout as a project. This is the first database I've made so go easy on me.
Anyways, I have tables "account", "order", "shopping cart" and "sku". Account holds the shipping info, name, phone, email, etc. The primary key is accountNumber. Order holds the billing information. It's foreign key is accountNumber and it's primary key is OrderID. Shopping Cart only has 2 columns-orderID and skuNumber. OrderID is the foreign key and skuNumber is the primary key. SKU has 4 columns-skuNumber, quanity, price, unit, and totalPrice. skuNumber is foreign and primary key.
My question is- the way I currently have this setup only 1 item sku can be ordered at a time. How would you design this differently so that wasn't necessary? I know I could do sku1, sku2, etc., but that seems like it would be against best practices.
Thanks!
Your database isn't normaized by this design, instead of the SKU table you will need two extra tables, becouse you simply need to separate the prodcts details(Name, price, etc...) from the Order details, so you will have to add the following tables:
Products:
Id.
Name.
Price.
...
Another one OrderItems or SKUItems that contains the following columns:
OrderID foreign key to the orders table.
ProductId a foreign key to the products table.
Quantity.
...
I didn't understand what SKU is but if it is some kind of product type, you can add an extra table ProductTypes: Id, name that holds product types, this table contains for example a product type called SKU then you can add a ProductTypeId to your Products, so you could have something like:
ProductTypeId | Name
------------------------
1 SKU
For the Products table:
ID | Name | ProductTypeId
-----------------------------
1 SKU1 1
2 SKU2 1
3 SKU3 1
I have two tables and I need to establish a 1-many relation among them, as an example:
1 Customer can have many Order(s).
What is a good way to create keys on the Order table such that there can be many rows in Orders, relating to one/same Customer details? i.e can I have cases when there are 2 rows with same CustomerID inserted into Order (1-many relation on CustomerID foreign key)
Assume
Customer table has columns:
CustomerID (key)
Name
OtherColumns
Order:
<IsaKeyNeeded>
customerID (foreign key)
OrderName
Another question I have is does 'Order' need to have it's own key?
You have it set up correctly ... the Order table should have a foreign key to the Customer table. This establishes the relationship of one customer to many orders. Just do not make the CustomerID a unique key.
To answer your other question ... yes, the Order table should have it's own primary key.