Which Is Correct

Hi, i am creating a small site which sells different types of products (i know there are several free off the shelf sites that are already built, so please do not let this influence your help)

I am thinking of setting up an ORDERS table which will holds various details about the order and then another table called PRODUCTS which will hold the various specific details about the product itself. Then i plan on storing the "id" from the PRODUCT table in the "product-id" field in the ORDERS table in order to link the product with the order.

This is an example of both tables:

ORDERS
id
date
receiver
product-id

PRODUCTS
id
product-name
price

I have two questions which i hope you can help me with:

1 - as i mentioned above i plan on storing the "id" from the PRODUCT table in the "product-id" field in the ORDERS table in order to link the product with the order... how should i name the fields in both tables considering there is an "id" field in both tables and a "product-id" field in the actual ORDER table...  i know you can work with 2 tables that have the same field name BUT is it best practice to avoid this... what would you suggest naming all of the above fields...

2 - i will be selling various different types of products (min of 5, max of 10), and all of these products have very different attributes that needs to be stored... so should i just make one big huge PRODUCTS table that will have a field that caters for all of the products and there attributes OR should i create a different table for each product type... for example some products will need a fields called "height", "width", "water-depth" etc... whereas other products do not have any values for these fields and need other set fields...

Thanks in advance for your help... looking forward to your feedback, thanks...
oo7mlAsked:
Who is Participating?
 
speak2abConnect With a Mentor Commented:
For 1: I would recommend
ORDERS TABLE
order-ID
Product-ID

PRODUCTS TABLE
Product-ID

For 2: This depends on your specific scenario. From your statements, the design recommendation i will give you is that: You don't need to create different tables for each product type otherwise you will be creating redundant fields and you will end up requiring several JOIN statements when you need to link these tables, thereby losing performance and efficiency. Again this is a design consideration that depends on what you envisage. However creating a Product table with product types as an attribute should be the way to go.
0
 
oo7mlAuthor Commented:
Hi, thanks for your reply...

I have been reading on google that

1: you should not use - (minus) and should use _ (underscore) instead...
2: id should only be id and not order-id and product-id... you should only use that when linking a foreign key

What do you mean "creating a Product table with product types as an attribute should be the way to go."
0
 
EyalConnect With a Mentor Commented:
I would design the database differently

Clients
ID(PK)
UserName
Password
FirstName
...

Orders
ID (PK)
DateStamp
ClientID (FK)

Products
ID (PK)
ProductName
Price

ProductAttributes
ID(PK)
Name

OrderAttributes
OrderID (FK)
ProductID (FK)
AttributeID (FK)
AttributeValue

this structure will not restrict you in the future and will give you flexibility to enhance the site more

you can also make a table linking product and attributes and possible values


0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
EyalCommented:
sorry missed important table

OrdersProducts
ID (PK)
OrderID (FK)
ProductID (FK)

and change the following:
OrderAttributes
OrdersProductsID (FK)
AttributeID (FK)
AttributeValue
0
 
speak2abCommented:
1: you should not use - (minus) and should use _ (underscore) instead...
I assumed you know that, I just followed your format to explain to you. Btw, you don't necessarily need to have even an underscore. You can have it as ProductID. There is no defined rules for the naming convention you use but it is important to be consistent. I particularly use prefixes for all items in my table.

2: id should only be id and not order-id and product-id... you should only use that when linking a foreign key
Again there is no hard rule to this, it really depends on your situation. This is mostly a practice for the study phase of databases. Imagine a situation where you need to find all the places where your field "ID" is used in some large script or program code. Searching for "ID" is meaningless (1000s of them!),

So my suggestions to you:
-it is recommended that every column name should be self explainatory or meaningful.
- common names and system identifiers like ID, NAME etc can be used  however such column names leads to confusion across data model. (The more you begin to code the more you will appreciate this)
-It is importand to keep consistency of column names across table wherever possible for better understaning of design, readability and to avoid mistakes while writing queries and to increase the efficiency.

Read More here:
http://www.smart-it-consulting.com/database/progress-database-design-guide/

Some best practices:
http://codebalance.blogspot.com/2011/07/20-database-design-best-practices.html

What do you mean "creating a Product table with product types as an attribute should be the way to go."

Read more about Normalization if you can. It is an important building block for DB design
http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/

These should keep you going.
0
 
oo7mlAuthor Commented:
ok thanks, so would you suggest actually calling fields:

ORDERS
order_id_pk
product_id_fk

PRODUCTS
product_id_pk



0
 
speak2abCommented:
No drop the pk and fk.

Firstly, I will suggest OrderID and ProductID. Notice the use of CamelCase in my example. Notice that the word ID is also in block letters. This helps the readability and future maintainance.

Secondly The foreign key and the primary key essentially should be thesame. Except you have special reasons not to.

Thirdly: The underscore is cumbersome to type, I would recomend dropping it except if you have special preference for them.
0
 
oo7mlAuthor Commented:
Ok thanks... my only worry using those is that they are case sensitive... i will re-visit my design and see how it fits, thanks
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.