Question

I posted this at ServerFault and was told this would be a better spot for it.

I have some experience as a developer but am a complete novice when it comes to SQL administration and database design.

I’m converting my company’s ordering and quoting process from a excel spreadsheet to something a little more robust using an ASP.NET application with a SQL backend.

Currently our parts database is just a excel spreadsheet. A lot of our products are just off-the shelf hardware from OEM’s like routers, servers etc. We are primarily a software shop so we install our applications on the equipment, configure the network equipment and ship out a complete solution that is installed by our techs.

In my schema I have 5 tables

• CompanyProducts
• OEMProducts
• SupplierProducts
• Suppliers
• OEMs

OEMProdcuts contains information from the equipment manufcaturer like Cisco, for networking equipment or Dell for server equipment.

SupplierProducts contains information about the suppliers we get the OEM stuff from (since a lot of OEM’s use resellers)

companyProducts contains the product ID’s specific to our company.

Here’s a snapshot from SQL Server Management Studio:

alt text http://i102.photobucket.com/albums/m108/ArkhamFreak/schema2.jpg

My question is:

What’s the best way to setup the primary keys for this simple schema? Should I use an auto-increment field as a GUID as shown in the diagram or the OEMProductID for the primary key to reference in all tables?

The Suppliers to SupplierProducts and OEMs to OEMProducts are obvious to me but the rest of the relationships I’m not so sure about. I’m a little worried that if I’ll have to refer to OEMProducts by an obscure auto-generated ID when I add data to a table that references it. Since we have more than one supplier for many of the same equipment, I’m not sure how to model that relationship.

Thanks for your time.

Answer 1

Well, a few thoughts:

• I would definitely not use the SupplierName as the primary key for your Suppliers table. Use something else – either you have some given item (e.g. a “Supplier Number” from some other system) that you can use, or if not, them just use a simple INT (possibly with an IDENTITY) to uniquely qualify each supplier

• Same goes for Product (use the ProductID, if that’s unique and stable) and OEM (again: use some kind of a given, unique item of information, but not a name, or create your own “OEM ID” of sorts)

• Why do you have a SupplierProductID and a OEMProductID on your SupplierProducts table? There might be a good reason for that – just not obvious to me at first sight.

I personally don’t like to overuse GUID’s – they’re cumbersome, they’re big and fat (when compared to an INT), they have all sorts of nasty consequences in your SQL Server indices (index and table fragmentation) – so unless you have a really good reason for a GUID (like replication amongst several physical locations), I typically prefer to use INT’s – either ID’s that I generate myself, or that I leave up to the database to handle (INT IDENTITY).