Need advice for Database structure (MS SQL / MySQL)

Preferrably MS SQL, I want to make the switch over from MySql.

So I have this awesome customer who has 4 Excel Files. Each Excel file represents a Product Range.

Within each Excel File, there are between 3 to 8 Sheets. Each Sheet representing a Type of Product within that Product Range.

Each Sheet, contains the following Columns:

PartNo, Description, QTY, Price1, Price2, Price3, Price4...

(There's never been, and won't be any more than 8 Price Columns.)

Each Sheet may contain from about 5 to 5000 rows.

Now, the problem I am facing now, is not knowing which would be the best way to go about setting up my new Database.

The way I currently have our existing MySQL Database is each Sheet represents a Table. That's it! (It had to be put "out there" quickly, hence the lack of time invested into setting up a proper format/structure for the DB.)

I've recently found that I am much more competent using MSSQL databases, so I want to make the switch, and the second reason, the main reason, is because I want to restructure the Database so I can make things easier to manage, and make it easier to setup Database searches from my site.

I'm not worried at all about How to insert everything into the database, as in my spare time for the last year I've written an app that parses these Excel files, extracts the sheets, and inserts them into the DB, with optional settings. I am worried about how I should actually setup this new DB.

What would be the best way to go about this given the above details?

Any help at all is greatly appreciated. Thank you!

Update:

About the Pricing Columns (Example), a little info on why there are more than one price columns in each sheet.:

Price column 1 may be Galvanised Unit Price, Price Column 2 may be Galvanised Box Price, Price Column 3 may be Stainless Steel GR304 Box Price, while col开发者_StackOverflow社区umn 4 may be Stainless Steel GR316 Unit Price. These price columns are different for each Product Range, however, some products in a Product Range may also contain some of the same Price Columns. This is why it was so easy to have each product as a separate table.

I assume that you're seeking advice on the design of the database, right?

I'd never design the database with each sheet representing a table. I'd have one table per conceptual entity, and in your case Product is the obvious one.

So a table called Products, with the columns you mentioned above. To accomodate the Product Type, I'd simply have a Type column that indicates which Product Type any particular Product belongs to. I'd eventually use an enum type in .Net to specify the different types that is supported.

Well, that was my five cents. Hope it helped.

A simple solution would be to split it out into 3 tables. ProductRange and ProductType are linked to the Product table through the foreign key relationships.

ProductRange
   Id
   RangeName
   // Plus any other columns you need. eg description, startdate etc

ProductType
   Id
   ProductTypeName

Product
   Id
   ProductRangeId
   ProductTypeId
   PartNo
   Description
   Qty
   Price1 
   // etc

If you wanted more flexibility around the price, you would create another Price table with a many-to-many joining table between the Product and Price tables.

Price
   Id
   Description
   Price

ProductPrice
    PriceId
    ProductId

Your Product table wouldn't contain any price columns in this case. But you are now able to add as many Price Types as you need and each Product could have any number of Prices.

Having multiple columns for price seems a little odd to me unless Price1 means "Business Rate" and Price2 means "Consumer Rate" or something similar. If the different prices are for different features of the same product, you might want to consider separating them out into a different table. For example:

Products table: KeyTable, ProductDescription...

Price table: KeyTable, KeyProduct, PriceType, Price

Alternatively, depending on how the prices are calculated, you could work the various other prices from one base price. For example, if a business rate price would be to add 5% to the base price and a consumer price would be to add 20% to the base price, these probably should not be stored in the database as they can easily be calculated when they are required.