I have a database I created for retail store data. I have three tables defined as follows:
Clients
id
name
Items
id
name
price
Purchases
id
client_id
item_id
So if the user enters a wrong Item name or price he would go to the item and make changes and it'll be fixed in all purchases (let's call this situation 1), but what if the product company decides to changes price for instance, if the user changes the price in item the previous purchases would changes as well. I thought of including the price in the Purchases table, but then situation 1 would be changing a lot of purchases.
My question is what is the best approach to work around this issue?
EDIT
Based on Gordon's comment, I did the following changes:
Items
id
name
price_id
Prices
id
price
effective_date
My question now is: I have more than 5000 item, wouldn't this slow my search?
Related
I am working on a project and I am a newbie in database. I need help answering the questions below with the scenario and the database tables listed.
Database tables:
Product (pid:integer, timestamp:integer, name: string, price:real, location:string)
Customer (cid:integer, email: string)
Purchases (pid:integer, cid:integer, orderid:integer, amount:integer)
Totals (orderid:integer, cid:integer, totalprice:real, timestamp:integer)
Scenario:
A product ID can occur multiple times in the schema. Each time the location or price is updated, another line is added to the database with a timestamp that indicates the time of change. The name does not get changed, so the same pid will always imply the same name.
Totals is a summary of the purchases table which shows when the purchases were made, and what the combined price of all products were.
Whenever possible, try to do your projections as early as possible.
Use the above database and provide queries for the following problems:
Find the names of products that at some point in time cost more than e20.00 and the names of products that have at some point cost less than e0.10.
Find the email addresses of customers that have spent more than e200 at once.
Find the pids of products that have had at least one price change.
Find the names of products that have both been displayed at location ’5-12’ and ’A3’
Find the cid of customers that have bought each product that at some point cost less than e1.00
Find the cid of customers that are registered with the store but have made no purchases.
Find the cid of the customer(s) that have made the largest total purchase.
Find the most expensive product that has been purchased at least once by each registered customer.
Find the pids of products that have not been sold since timestamp 20150625 but have been sold at least once before that date.
The grocery store wants to improve its database. Write a query that returns a table that is basically the Purchases table plus the price of the product at the time of purchase.
Let's try to provide you a bit of help to start your project ❤
In query one, we need to work exclusively with table Products, and You want to find the name of those products with price above x and less than y.
First, the columns we want to get FROM the table:
SELECT name, price FROM Products
Then, as you need a query that get products more expensive than 20, and producs less expensive than 0.10, you could use the Condition BETWEEN reverted with NOT:
SELECT name, price FROM Products
WHERE price NOT BETWEEN 0.10 and 20
And you can order it to be more readable:
SELECT name, price FROM Products
WHERE price NOT BETWEEN 0.10 and 20
ORDER BY name ASC;
I'm not sure if this is what you need, but I hope it helps a bit!
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 am designing a schema for E-Commerce app, in which I would have 3 tables i.e Orders, Products, Customers.
So Should we store customer_id and product_id in Orders table straightaway.
The limitation to this is when a product or customer updates their attributes( i.e product price or customer name ), the orders table doesn't reflect them.
For Ex: A Customer bought a product at $10, but later on the product price gets updated to $20.So now when we are referring to this order by product id we would get the result as it was bought at $20 instead of $10.
SOLUTION 1:
One solution would be to insert a new row into products table whenever an updates occur and perform a soft delete to that product so that it can be referenced from orders table.
SOLUTION 2:
Store most of the details in product and customer details in orders table.
SOLUTION 3:
Create a temporary table of customers and products whenever there is an update to these tables.
I am very much open to any other suggestions.
One thing that you seem to be missing is a orderLineItem table for anything other than the most simple solution, where there is one product/order.
Now, that being said, you can do the products table in several ways.
Assuming that price is your only variable in the products table that you want to change, you can have a separate pricePoints table, that would store the price for any item at any given time. You would then use the ID from this table in your orders table and use that to get to the productID from the products table. A slightly more inefficient way to store this (but faster for retrieval) would be to store both the productId and the pricePointId in the orders table.
You could also do this by simply storing the price paid amount in the orders table. This gives you a little more flexibility to add discounts and pricing rules. You do need to be concerned about auditing the price though if you do it this way. Why was this price charged for this line at this time is going to be a common question.
You need to know how much the customer paid for the product at any time. It's not so important to know how much the customer would have paid for the order if they bought it today.
Customers are a slightly different issue. Some of the information in a customer table is transient. Some of it has to be fixed for the order. Lets say that the customer has a name, address, billing address and shipping address. At the time of the order, the shipping and billing addresses have to be absolutely fixed. You don't want to go back in three weeks and discover that the shipping address was changed. But, by the same token, you might like the name to be updated if a customer changes their maiden name, for example.
Now, all that being said, we aren't going to design your schema for you. There are a lot of good resources out there for how to design a simple e-commerce database.
I am building a very small shopping cart system with php/mysql. Currently the actual shopping cart (less tables for products, categories and such) consists of two tables.
One table named shoppingCarts which includes the following columns:
id (PK)
userId(FK)
dateCreated
The other table, named shoppingCartItems, consists of:
productId (FK)
shoppingCartId (FK)
dateCreated
To add the amount of one product I can think of two possible scenarios:
Add a new row for each item added to the shopping cart.
Add a column 'amount' and store the amount in there.
I am wondering which option would be best, what are the ups and downs?
Maybe there is an even better solution I didn't think of?
I think, the right solution is to have an extra column for the amount, because there is no advantage having one row per item but more redundant data. Imagine if the customer wants 50 items, you would end up with 50 identical rows of data. And you have to count the rows, either with a GROUP BY select or programatically. With the extra amount column you save data and your queries are less complex.
What I suggest is that there is no use of using only an amount column.
As I believe you have an item table where you have the item id, details and its price.
So the flow goes like::
If a customer logs in create a row in shopping cart with his userId, and whenever he adds an item to his cart a new row is created to shopping cart items. Now the cumulative price of all the items can be found and displayed(using the aggregate function sum), which will solve the purpose of creating a new column "amount".
Moving forward, say in your application if you integrate the concept of discount coupons or any discounts to any loyal customer, our design will be tough to integrate. So what I suggest is adding two columns
1) Total Price
2) Discounted Price/ Amount Paid
Please revert in any case of any doubts.
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.