Hi Walter,

I think for the bandwidth issue, a lot depends on your application and the market for your application.

Our application is a records management system for fire departments. Some departments have stations scattered in rural areas and, unfortunately even in this day and age, many are still connecting via dial-up. We obviously have no control over this, so bandwidth is an issue for us. Some of our data has a lot of child records plus we use FKs to all the various code tables, so there could be a lot of FKs ... if you have a lot of GUID FKs in addition to the GUID PKs, it starts adding up.

~~Bonnie



>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,