My company was using this model to manage the inventory
Model 1 http://img534.imageshack.us/img534/6024/modeltest2.jpg
But i was having problems because in this month we bought some plastic bags with a different price, expiration date on the same warehouse.
So now i changed the model to this.
Model 1 http://img16.imageshack.us/img16/8416/modeltest.jpg
My question is if this is ok.. it is working but is the first time i create a table with only no Primary key.
Example of Data:
PRODUCT WAREHOUSE Quantity Price Expiration_Date
PLASTIC BAG NEW YORK 20 1.20$ 12-10-2013
PLASTIC BAG NEW YORK 130 1.50$ 21-12-2015
Thanks
Basically it's OK. In Sales, Warehouse systems you can't save all products with different expiration date in Product Table, because there would be a lot records for each product. But usually you need to save them in "Item_Ledger_Entry" Table where would be all Transactions of Sales or Purcahse.
You using one same Product just with different expiration Date. I think you don't need at all Priamrey Key in Product has warehouseKey
One problem with this, specific to MySQL and InnoDB storage, is that InnoDB will silently create an extra 6-byte integer internally to serve as a surrogate primary key. Also, queries against any InnoDB table are more efficient if you can do them via the primary key. So it's to your advantage to define a primary key (or unique key) if possible.
If the combination of columns Product_ID, Warehouse_ID aren't sufficient to uniquely identify every row, then you could add a third column to distinguish between duplicates. For example, Stock_ID or something.
Related
I have a database of 5 tables. Some contain the same columns as others, does tying these tables to another table which has the primary keys of other tables meet 3rd normalisation. (This is outlined more clearly below)
I have a table of customers, with their names and phone numbers as well as requirements they want in their car etc. The primary key is CustomerID.
I then match a customer with a car which matches their requirements. I have a table with Match ID (Primary key) and CustomerID and CarID (As foreign keys.)
By doing this, can I then make a table off Match ID which can be given to the receptionist so that they can contact the customer. In this table I would need to include the customer name and phone number. However, does this break 3rd normal form as Phone number is now both in CustomerID and the new table.
The last table you describe doesn't necessarily break any normal form, because the customer's phone number can change in the future. You may want to preserve the phone number in another table so there is a record of what phone number was contacted on that date.
Compare with a database of products. The product table has prices. Then you record customer purchases, with a copy of the price they paid on the date they made the purchase. That's okay because you need a record of what was paid in each case. A customer may buy the product during a sale, or they got a senior discount, or a bulk discount, or the price may change a month after they bought the item, etc. The price they paid is not necessarily the current price recorded in the products table. Therefore it does not violate 3NF.
I'd like to implement a relational database that stores the holdings of different mutual funds at different dates. In other words, each observation is a unique combination of a mutual fund, a stock, and a date. Each combination of those 3 variables also has a corresponding data point for the number of shares of the stock the mutual fund owned on the given date. From what I understand, I cannot implement this with two simple many-to-many relationships between the stock, mutual fund, and date variables.
The reason for this is that while a combination of a mutual fund and date, and stock and date might exist, the unique combination of the mutual fund, stock, and date might not. For example, Apple (the stock) might exist on 12/31/2015, and Fidelity Contrafund (the mutual fund) might exist on 12/31/2015, but Fidelity Contrafund might not own Apple on 12/31/2015.
Any relationship with any number of roles can be represented as a table. You'll have columns to identify each of the domains, as well as any dependent variables. Then, create a composite primary or unique key from the components in many-roles.
For example, you could create the following table:
holdings (mutual_fund PK, stock PK, date PK, shares)
Some people prefer to introduce a surrogate/autonumber key as primary key. That's fine, as long as the combination of (mutual_fund, stock, date) is indicated as a unique key.
MySQL Workbench, and other data modeling programs like it, use pre-relational (and pre-entity/relationship model) concepts when they equate tables with entity sets and foreign key constraints with relationships. They're still good for designing table schemas, just ignore their terminology.
I am converting a spreadsheet to a database but how do i accommodate multiple values for a field?
This is a database tracking orders with factories.
Import PO# is the unique key. sometimes 1 order will have 0,1,2,3,4 or more customers requiring that we place their price tickets on the product in the factory. every order is different. what's the proper way to accommodate multiple values in 1 field?
Generally, having multiple values in a field is bad database design. Maybe a one to many relationship will work in this scenario.
So you will have an Order table with PO# as the primary key,
Then you will have a OrderDetails table with the PO# as a foriegn key. i.e. it will not be designated as a primary key.
For each row in the Order table you will have a unique PO# that will not repeat across rows.
In the OrderDetails table you will have a customer per row and because the PO# is not a primary key, it can repeat across rows. This will allow you to designate multiple customers per order. Therefore each row will have its own PriceTicketsOrdered field so you can know per customer what the price is.
Note that each customer can repeat across rows in the OrderDetails table as long as its for a different PO# and/or product.
This is the best I can tell you based on the clarity of your question.
Personally, I normally spend time desinging my database on paper or using some drawing software like visio before I start implementing my database in a specific software like MySql pr PostgreSql.
Reading up on ER Diagrams(Entity Relationship diagrams) might help you.
You should also read up on Database normalization. Probably you should read up on database normalization first.
here is a link that might help:
http://code.tutsplus.com/articles/sql-for-beginners-part-3-database-relationships--net-8561
I'm working on a very simple DB.
Imagine I've table customer and table seller.
The customer is able to request a quotation for some products
There will be a simple form that allow to customers to select products and submit the quotation.
Now, should I create table : "Quotation" and store all quotations (with id_quotation..etc)?
Thank you all
Without knowing all of the business rules that govern the requirements of this database, perhaps the following design will help to answer your question and explain a few concepts in the process.
In database terms, an entity is a person, place, or thing about which we want to collect and store data. From your description we can already see two entities: seller and customer. This is important since the entities we identify conceptually become database tables in their own right.
The seller table should contain data applicable only to sellers. Thus, the qualities (attributes) about sellers that we want to store become columns in our seller table. Each row (record) in the seller table represents an individual seller. Each individual seller is uniquely identified in the seller table with a unique value stored in it's primary key column, which we can name seller_id.
A simplified version of such a table could look like this:
In a similar manner, the customer table should contain data only applicable to customers. The qualities (attributes) about customers that we wish to store become the columns in the customer table. Each row (record) in the customer table represents an individual customer. Each individual customer is uniquely identified in that table with a unique value in it's primary key column, which we can declare as customer_id.
A simplified version of this table:
I'm guessing the business rules state that any customer is able to request any number of products, from any seller, any number of times...since surely any seller would want as many sales and customers as possible!
How can we express and record the interactions (relationship) between seller and customer?
This is done with a new kind of entity: a composite entity. It becomes a new table, having it's own primary key, and contains seller_id and customer_id as foreign keys. The foreign keys in this table connect (relate) the seller table to the customer table.
We can name this new table quotation (if that is your preferred name). Each row of this table is intended to capture and record each and every individual transaction between a customer and a seller. The columns (attributes) of this table are the data that apply to a transaction between a customer and seller, such as amount or date of sale.
A very simplified version of this composite entity:
Note that the foreign key values that exist in this table must already exist in their respective tables as a primary key value. That is, a foreign key value cannot be entered into this table unless it exists already as a primary key value in it's own table. This is important, and it is called referential integrity - it ensures that there is no record of a customer purchasing from a non-existent seller, etc.
In the example above we can see that Builder B requested a quotation from Acme Construction in the amount of $3500.00. They then requested another quotation at another time for the amount of $1800.00. What else does it reveal? All existing customers have ordered something. Acme Lumber has not made a sale at all (yet), etc.
A design such as this enables the database to store any number of transactions between sellers and customers. Likewise, it supports the addition of any number of new customers and sellers, even if they have not sold or purchased anything yet. Queries can be run that reveal which sellers have sold the most or least, and so on.
Good luck with your studies!
The order_products table holds data of products with the product name and price. It has a list of records what customers have bought.
There are also two fields called product_name and price which are duplicate data from the products table.
It is worth it to normalize order_products table and create history (audit) table for product name and price? Then I don't need product_name and price in the order_products table anymore?
I assume you need to store product name and price at the time of the order. Both will change in the course of time. If that happens a lot, your current approach may be good enough.
I would consider a normalized approach, especially if you have many rows in order_products per (product name, price). Have an additional table that stores the volatile states of a product every time they change. Could be called product_history like you already hinted. Just save the date (or timestamp) with every new state. Have a foriegn key link to the table product to preserve referential integrity. Like this:
create table product_history
(product_id integer -- or timestamp
,valid_from date
,product_name varchar
,price decimal
,PRIMARY KEY (product_id, valid_from)
,FOREIGN KEY (product_id) REFERENCES product(product_id)
ON DELETE CASCADE
ON UPDATE CASCADE)
A fast query to look up the applicable volatile attributes:
SELECT *
FROM product_history
WHERE product_id = $my_product_id
AND valid_from <= $my_date
ORDER BY valid_from DESC
LIMIT 1;
You definitely need an index on (product_id, valid_from) to speed up this query. The primary key in my example will probably do.
That depends. What is the purpose of that table?
In general tables like that can be used to statistical analysis of market trends so its important to have both product_name and price because the product price today may be different than what it was one month ago, but you may want to know at which prices products were most bought.
However if the presence of the price in that table is due to the fact that the price may be part of the products primary key then that is just bad practice and the key should be reduced.
It's not possible to make this judgement knowing just the database structure. It depends on how you use your database (ie. inserts, selects, updates and deletes... And how frequently?).
In one end, if your solution was a reporting solution on a read-only database, you should keep those duplicates! But if on the other end your solution is a logging solution that only logs information but never retreives, I'd go for the denormalized model you're suggesting.
Fully normalized database are not optimized for performance. You often have to denormalize your database design..
Very often a model that has a certain degree of redundant data is the fastest one. When denormalizing you just have to keep a steady eye on the balance between faster queries and slower insertions/updates!
Check these answers and maybe you'll find further help making your decision! When to Denormalize a Database Design
Yes that's a good idea, but a better idea is to create one field in order_products table and dump all your order info there after serializing them. With this approach you don't have to create 2 new tables (may be more if you want to do the same for gift coupon info, shipping info etc etc)
Rationale behind the approach is that order_products are placed order which means they are "published records". Published records don't change much and shouldn't be modified. And these records should be kept for future audits.