CJ's comments on normalization are true and appropriate. However, there comes a moment here where you need to LOOK at the data to decide which columns can reasonably become candidates for normalization. Another equally important issue is whether it pays to normalize or to otherwise reformat. A little bit of up-front skull sweat usually pays off BIG time for big data sets.
For example using CJ's data from post 16 and taking an assumption that your data comes in as all text (because I remember reading about your other post with a big CSV data set)...
Reformat examples first:
If your import is purely CSV and you don't do conversions, you probably get everything as text. Look at CJ's field called "Invoice No." which is a 5-digit number. If you store this as a string, it takes up 5 bytes. If it will ALWAYS be purely numeric, though, you can store it as a 4-byte LONG integer. That's a savings of one byte per record. Not so much, you say? If you have 100,000 records, you just saved 100,000 bytes.
If you have a date in string format, you assume dd/mm/yyyy text format which is 10 bytes. If you convert the string date to a DATE field, you have the same information in 8 bytes (the size of a date field). Then considering 100,000 records, you have saved 200,000 bytes. AND date order works OK sorting date fields, but text fields have to be in yyyy/mm/dd format to sort correctly by date.
Normalization:
Note CJ's customer code and customer name examples. If you have 100,000 records but only 1000 distinct customer codes and customer names, make a customer table that includes an autonumber plus the customer code and customer name. If you make the customer table first, then when you import the main data and you only store the unique autonumber in a record (by looking up the customer code from the customer table), the math says you store 1000 customers x (autonumber, 8-character code, and at least 7 character name) = 19,000 bytes (minimum) in the customer table + 100,000 records x 4 bytes in the main table = 419,000 bytes between the two places. If you DID NOT normalize but instead retained the code and name (at least 15 bytes) x 100,000 that would be 1,500,000 bytes - three times as many as if you normalize. And I'm betting customer name could be more than 7 bytes.
This savings in space utilization is WHY you spend time up front planning how you want to store things and WHY you want to include normalization among the tools in the tool box. That up-front analysis and planning saves your skin more often than you would ever realize.