Database Normalization precautions

Okay. So at my place of work there is a products table in our sql database to hold information on our products (go figure). However the company that created the table (our former web vendor) apparently did not believe in using more than one table to hold the data. So what that amounts to is a 201 column table with a column for nearly every related and unr开发者_高级运维elated piece of data you can think of. Obviously, I don't want it to be like that anymore. I have created logical tables to divide the data into that contain the columns from the original. How do I go about populating the new tables with the data from the original? I know this is kind of a general question and I am looking for a general answer. I don't need specifics I just need to be pointed in the right direction. Thanks

---

Look up database refactoring on the web.

Basically, don't create any tables or move any data. Instead, create SQL scripts that do the job in addition to an SQL view that recreates the original table layout virtually. Also some code that validates that view, probably by comparing the original table row by row. Then run the script, check the data, and when you have it exactly right, delete the monster table and rename the view to take its place.

Hopefully you do know about SELECT INTO to get the data into the new tables. You would do things like SELECT DISTINCT clothingtype FROM bigtable INTO clothingtypes;

---

You select the columns you want to insert, for all or some of the rows from the original table, and insert this set into the destination table. Are you familiar with the SQL UPDATE and INSERT statements? EDIT: You'd want to relocate only those columns that do not relate to every row; if the column pertains only to some rows, those rows/columns are candidates for relocation, if normalization is the goal.