How to normalize category database [closed] - mysql

Question

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've got a MySQL DB with ~5000 rows. It occurred to me that before adding anymore records or columns I need to get the database normalized. But even with all the research I've done I'm struggling to understand several concepts. Here is an example of my existing database schema.
PK Category1 Category2 Category3 Produce_String Keywords Zip State City Country
1 Vegetable Potato f5kkfid34fbn organic ... ..... ... .....
2 Vegetable Potato plf85jfuvj organic,fresh ... ..... ... .....
3 Vegetable Cherry Tomato jf9vmu37jg9 fresh
4 Fruit Lemon kfkt8hkf0e fresh,yellow
5 Fruit Lemon fkg8rr03gnf
6 Fruit Red Apple fkf9gkty367r6 crispy
My main misunderstanding, is how to relate the data to one another once the columns are separated into individual tables? For example, in a DB client I can see the rows and how they relate to one another, but if I separate them this will no longer be the case. I am also concerned with having to update multiple tables for the same record but I suppose this is unavoidable.
Also, I'm not clear on the proper way to normalize this. My mind tells me to only separate the Keywords column since it's the only column that has comma separated entries. But by normalization standards I believe I need to separate the categories, keywords, and location.
EDIT
Another concern I have, is that if I put the categories in a separate table, each with their own row, I lose the structure. So I lose the ability to sort by the specific categories. For example, the vegetable category would not be related to a fruit. Since the Produce_String is unique, could I use it as the foreign key in the other tables?

Answer 1

You can have separate Category and Keywords tables
category keyword
------------------------- -------------------------
id | name id | name
1 | Vegetable 1 | organic
2 | Potato 2 | fresh
Than make two additional tables for MANY TO MANY relations:
category_to_product keyword_to_product
------------------------- -------------------------
category_id | product_id keyword_id | product_id
1 | 1 1 | 1
1 | 2 1 | 2
2 | 1 2 | 2
And to update categories for product #1:
DELETE * FROM `category_to_product` WHERE `product_id` = :product_id;
INSERT INTO `category_to_product` (`category_id`, `product_id`) VALUES (1, 1), (2, 1), (8, 1);

Answer 2

This is a question with a potentially long answer, and you might be better off starting with somewhere like wikipedia or similar. But in a nutshell:
Normalisation usually solves more problems than it causes. Consider someone who spelt "Vegetable" as "Vegteable" for one of the rows in your example, or consider if you wanted to add a fourth category. Or what about if you wanted to change all instances of the category "Baby Marrow" to "Zuccini". You are correct that both of these could be implemented as separate tables.
One of the criteria that you can use for deciding whether to normalise or not is to think about where you want to control the integrity of the data. You may be in control of application code now, that ensures that the category names are always used consistently, but it's hard to foresee what applications will come in the future. Keeping the list of categories in it's own table makes sure that when you link two products to the same category, they are indeed linked to the same category (i.e. the single row "Vegetable" in the category table). When you change a category, you can change it in one place. You can easily find all products linked to a single category before you delete a category, and so on.
Yes, once the data is in separate tables, you don't see it all in one row any longer, but joining the data is what relational data is all about, and you can probably use database views to recreate the layout that you've shown us from the underlying normalised data. It is very normal to join several tables in an SQL select statement.