Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Your thoughts please
Message
From
07/12/2005 03:24:01
Walter Meester
HoogkarspelNetherlands
 
 
To
06/12/2005 16:54:15
General information
Forum:
ASP.NET
Category:
ADO.NET
Environment versions
Environment:
C# 1.1
Database:
MS SQL Server
Miscellaneous
Thread ID:
01075336
Message ID:
01075596
Views:
12
Hi bonnie,

>We use bigints for our PKs. I'm not against using GUIDs for storage reasons ... we have a GUID in every table but we don't use them as PKs (they are in there for future use, in case we need some unique identifier for merge/replication or something). However, the main problem, IMHO, with GUIDs is NOT the excess disk space they take up (with the price of hard drives nowadays, that's not an issue at all), but the bandwidth they take up coming down the wire. For that reason, we NEVER retrieve the GUIDs into our DataSets.

Personally I don't use GUIDs but have my GETNEWKEY() SP in the database and I'm confortable with it. Even on the internet my applications seem to run very fine. (Tip, let your GETNEWKEY() SP accept a number parameter that specifies how many keys you want, so you'll eliminate extra rountrips if you have to insert multiple records in a batch)

Bandwidth IMO, is getting a less important factor. On a 100Mbps network it really is no issue unless we talk about high volume of transactions or large resultsets. Even on the internet where 512Kbps to 1024Kpbs connections are affordable and not an exception anymore I could not care so much for an extra 8-12 bytes per PK and FK going accross the line. I'd like to see some statistics where it is proven to make a difference. Storage space and performance of the database itself are a much bigger concern if you ask me.

Another much bigger concern if you ask me is the number of roundtrips needed to complete a transaction. I did a few tests on the internet with one of my applications. From Toronto, Canada to Holland which is 6000 straight Kilometers the time lag between sending the SQL command and retrieving the result really was the one that degraded the performance (still quite acceptable though). The same tests over the internet between two locations in Holland (200Km) the performance was excellent. In fact I could hardly notice that I was working through the internet.

In short, there are a few factors to consider:
- Bandwidth
- Time lag of extra roundtrips
- Database size and it relation with server performance.

Walter,
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform