Thanks, Walt.
I have gained some knowledge about the types of relational tables from recent reading and it is great that you pointed out the aspects of migrating from Excel to SQL.
What I am trying to work out is a product list for research labs. Here is a snapshot of how the categories look like.
categoryID categoryName motherCategoryID
1 reagents null
2 proteins 1
3 DNA engineered Proteins 2
4 enzymes 2
5 antibodies 1
6 primary antibodies 5
7 labeled primary antibodies 6
8 unlabeled primary antibodies 6
9 second antibodies 5
10 buffers 1
11 pH buffers 10
12 non-pH buffers 10
......
You can tell under the main category 'Reagents' there are several sub categories and each of those include another level of sub categories and it goes on more levels.
It is easy work to create a product label, but I am pausing at how to make this category table, so I can properly relate the products.productID to categories.categoryID.
I feel I should adopt the categoryIDs of those lowest level categories. For example, for product phosphate buffer, I should link it to #11 pH buffer rather than #10 buffers.
More about the category table: Originally I thought I need a category table and a sub-category table, but that doesn't work, because some categories have one lower level sub-categories and some have several lower levels. Making different data sets for different categories will for sure solve this problem, but that makes the database much complicated. So I figured I may create a categories table like the one I just typed.
I don't yet know if this is a totally dumb idea.
At least this illustrates what I am trying to do. How would you database categories like this?
Try reading the following article for guidance. http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html. Life becomes a lot easier when you understand the basic principles of normalization.