I am trying to obtain the lowest price for a product from a table of product prices per store. Also, i want to validate if the amount entered by the user exist in the STOCK table as well.
Take note:
A user has an address and this address is associated with a zipcode.
The user will be able to choose different products from table
"Products", these products exist (or not) in different supermarkets
and the supermarkets have different zipcodes (in my model zipcodes
from table address and table market are the same).
Inside Products table there are multiple items that belong to
different supermarkets and they have different prices. I only want to
insert inside LIST table those items that have the lowest price
compared to other supermarkets. If an item has the lowest price but
the zipcode of the supermarket does not math to the zipcode that exist
in the user table then it will be inserted other register from the
other supermarkets (with the lower price). The stock will be checked
everytime
Take a look at this:
sqlfiddle
This is an example(i cannot upload images yet):
image
I have been trying so many times without success.I used min function in order to obtain the lower price:, ie:
SELECT idProduct
FROM product
WHERE price = (SELECT MIN(price) FROM product);
Then,i tried to use not exist function in order to solve this but i failed.
Could you please help me?
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!
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?
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.
Say I have a property listings table and a listings_categories table which determines if the listing is for sale, rent and/or season rent. Depending which categories a listing has (min of 1 required), a price value or timespan (in case of season rent) may be required.
How should I deal with these price fields? Should they be placed in the listings, or move them to the listings_categories table? These price fields are somewhat essential to the app and will always be displayed -- would I have any problems appending them to the rest of the main listing table?
I would say if listings_categories only has one column and 3 possible fields, you ought to just store all of that in the listings table. No reason to join when you don't have to.
If the sale, rent, and season rent values are always specific to the listing (all listings have specific values), and not to the category (values for all categories are the same, regardless of listing) then your listings table is where I would put these fields.