I have problem with two parts of database diagram and I need your guidance:)
database has a lot of tables that one of them is about Employee ,the other is about Customer and ... ! I have problem with two tables (Product and OrderDetail) my Product table has 3 columns (ProductID,Name,Cost) and the Other table is OrderDetail that has these columns(OrderDetailID,Cost,Quantity) I have not created this database myself I have found it like a sample database in the internet but I have problem about these two Cost which is in OrderDetail and Product tables ,what is the difference between these Cost? they are the same or not?
thanks
EDITED: sorry all I had a mistake ,the ID for the ordeDetail table is the composite of primary key of Product table and Order table which is Product ID and OrderID and the OrdeDeatil table is a weak entity. SO
OrderDeatil((ProductID,OrderID),Cost,Quantity)
I suppost that the cost in the products table is the current price of the product. On the other hand, the cost in the order details table is the price that was paid for the product for that particular order.
Product prices can go up or down, or discounts might have been given for particular orders. The field in the order details table would store this information.
UPDATE: Further to your updated question, that makes sense. It implies that each order can only list the same product once. The order details table is storing how many items of that product were ordered (quantity) and I would say that cost is the price paid for one item. It could be the total (price * quantity) but that's not a common for such table structures.
Without knowing exactly what this database is meant to capture, I couldn't say for sure, but as a rough guess I would expect that the Product tables Cost column is the cost for a single unit of that product, and the OrderDetail tables Cost column is the cost for an order of some quantity of 'something' - most likely a certain quantity of a product. Note as an interesting aside that there is nothing linking the OrderDetail table to the Product table - if these two tables are meant to be linked you would normally expect a Foreign Key in the OrderDetail table linking it to the Product table. At the moment, there is no way to match OrderDetails to Products.
Related
I have two tables. 'Products' and 'Discounts'.
Then I create a joining table 'discount_product' for Many-to-many relationship. So far so good.
Now if I want a discount to belong to ALL of the products I have to make insertions into the joining table for as many products I have. That means that having 10000+ products I'll have to insert 10000+ rows for one discount into the joining table? And that's only for one discount! What if I have 1000?
That's compelling me into returning to the old (wrong) way of doing it when I just have a column 'product_ids' in the 'Discounts' table with something like this '1|2|4|7|23|...' (or '*' for 'belongs to all') and then make a small piece of PHP code to check if discount belongs to all or to some products. I know it's wrong way of doing it. So is there a better way to make this properly?
Structure:
**products**
id
description
price
**discounts**
id
procent
value
**discount_product**
product_id
discount_id
I propose to try to change some business logic.
If the discount is not in the discount_product then this means that it applies to all products.
If the discount is in the discount_product then it means that it works only for a certain product.
If you need to ensure that the discount is not applied to any product, add the field is_active in discounts.
It's just my thoughts.
I believe that sometimes it is useful to denormalize the database because of optimization, and I would do as you suggested with the product_ids field.
Suppose I have a table for purchase orders. One customer might buy many products. I need to store all these products and their relevant prices in a single record, such as an invoice format.
If you can change the db design, Prefer to create another table called PO_products that has the PO_Id as the foreign key from the PurchaseOrder table. This would be more flexible and the right design for your requirement.
If for some reason, you are hard pressed to store in a single cell (which I re-iterate is not a good design), you can make use of XMLType and store all of the products information as XML.
Note: Besides being bad design, there is a significant performance cost of storing the data as XML.
This is a typical example of an n-n relationship between customer and products.
Lets say 1 customer can have from 0 to N products and 1 products can be bought by 0 to N customers. You want to use a junction table to store every purchase orders.
This junction table may contain the id of the purchase, the id of the customer and the id of the product.
https://en.wikipedia.org/wiki/Many-to-many_(data_model)
Is there any problem in making a relationship that joins 3 tables with 3 relations?
In my case I have Sales, Sale Details and Products.
I related products and details of sale because I can enter multiple products in details. On the other hand, I related Products Selling because I need some products that belong to a sale.
Is wrong I do this kind of relationship?
I reedited my tables :
Sales: sales_id, date
Sales_Details: sales_id, prodSale_id
Products: product_id, product_info, cost
Products_for_Sale: prodSale_id, product_id, price
Consider the following situation :
I have a table where Products_for_Sale products belonging sale appears only once. This table is needed because I need to change the selling prices of the products manually, as needed, without changing the overall product table. ( Note that I manually changed the products 1,2,3 and 4 Products_for_Sale).
Note that products are repeated for sale because it is a necessity of the business rule (Products are repeated I have more fields that require repetition of the products).
For this reason I needed a helper where I put these products only once (Products_for_Sale) table.
But I thought about putting a sales_id in Products_for_Sale column to know which belongs to each product sale.
Does my modeling right now ?
It would be better to have 3 tables in the following manner.
1) Sales (sales_id, date,..)
2)Products(product_id, product_info,...)
3)sales_products(sales_id,product_id)
This is normalized and the best approach for many-many relationships. look here for more info
I have a database design issue. My project is about products and retailers.
Product table: product_id, product_name, product_description, category_id, quantity_per_unit
Retailer table: retailer_id, retailer_name, City
Retailer's Stock table: retailer_id, product_id, unit_price, availability
The Retailer's Stock table links each product with its seller
And also Category table with category_id,category_name,category_description
Now I want to have different sizes, colour and brands in product. How should I accommodate them in this database? I have included the price in another table then products table because different retailer can sell the same item at different prices.
Your existing database design already meets your stated requirements. Each instance of a combination of size, colour and brand in a product is a row in your Product table. This is often called a Stock Keeping Unit (SKU).
If you want to have products at a higher level, think of breaking your current Product table into two parts, like so:
ProductType ( product_type_id, product_type_name, product_type_description,
category_id )
SKU ( sku_id, quantity_per_unit, product_type_id )
Then amend your RetailersStock table to reference SKU instead of Product.
This is a common problem with stock keeping systems; different colours, sizes etc. are usually called "variants". There are other questions on StackOverflow.
There are often two questions that intertwingle here.
One is "I'm selling soap, towels and bulldozers; how do I design a schema that allows me to store and reason about the attributes of those products, when they're all different and I don't know in advance what the attributes will be?". I'm going to assume that's not your question right now.
The second question is "how do I keep track of stock, price etc. for variants?".
The classic answer for this is to have a "product" table with the attributes that are common to all attributes, and a product variant table that has the attributes specific to the variants, along with the quantity of stock and the price (if variants can have different pricing, e.g. a large pack of soap is more expensive than the small pack).
Product table: product_id, product_name, product_description, category_id, quantity_per_unit
Product_Variant table: product_variant_id, product_id(FK), size_code, colour_code
Retailer's Stock table: retailer_id, product_variant_id, unit_price, availability
You do, then, need to keep a variant for all products, even if there is only one version for the product, but it's usually a good idea to factor out the "core" of the product data from the more fleeting data like availability and price.
I have a 3-table schema. Two of the tables (Trade/Portfolio) have a 1:1 relationship, so the FK on one of these tables has the unique constraint.
The table, as explained above, with the FK (which is Portfolio) relates to a third table. As this third table (Price) is displaying historical information for a Portfolio (there can be many prices for a portfolio over a time-period), there's a bog-standard 1:m relationship.
However, I need to get the various prices for a portfolio. That's easy with a query which works on the portfolio ID. However, is this a feasible way to get the price of a single trade? Is there any limitation in the design that would prevent this?
Apologies for the long title, but could not find a better way to explain the issue!
Thanks
By your description I guess this is your data model. FK TradeID is a unique in Portfolio.
And you wonder if it is possible to get the rows from Price related to Trade.
Here is a query that will give you all rows from Price where TradeID is 1.
select Price.*
from Portfolio
inner join Price
on Portfolio.PortfolioID = Price.PortfolioID
where Portfolio.TradeID = 1
I see nothing in this design that will prevent you from fetching the rows from Price given a TradeID.