Using GUID versus Autoincrement Values

  • Thread starter Thread starter William \(Bill\) Vaughn
  • Start date Start date
W

William \(Bill\) Vaughn

The numbers are tough for users to enter... that seems to stop some folks.
But they are easier to code.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Hi,

I am currently designing in application that uses a SQL Server DB as a
backend. Some of the tables are structured to use autoincrement values as
keys (child tables). Recently, I have come across the idea of using GUID as
keys instead and have them created on the client. This would eliminate the
headache of managing the update and autoincrement keys. Other than the size
of the GUID, is there any issues with this approach?

Thanks
 
The numbers are tough for users to enter... that seems to stop some folks.
Click to expand...

I usually generate them via code, since no living being would want to
manually type a GUID :-)

Massimo
 
If you develop your application in such a way that the user never has to see
or type a primary identifier (there are some really good ways to do this)
then there could be a number if advantages to doing it that way. ESPECIALLY
if you ever have to indert complex datasets into the database
 
Why not use a uniqueidentifier datatype on the server? I have read
literature from Microsoft in the past that suggests that a uniqueidentifier
is the safest way to create a primary key column, as compared to the
identity column. Though I have never had any issues with an identity
column, I can certainly see why the uniqueidentifier would be the safer
choice of the two.

As for space, well disk space is cheap these days.

Dale
 
Hi Jack,

You'll pull your hair when you'll try to examine records manually in
database :)
 
SQL Server will implicitly convert it to char, varchar, binary, or varbinary
(or unicode equivalents) so you could cast it as a char when selecting it
from SQL and use a string in your dataset. Going back to SQL Server from
the dataset would be handled by the implicit conversions in SQL Server.

Dale
 
What do I set for the column type to represent GUID or uniqueIdentifier in a
typed DataSet?

Thanks
 
Hi

I have an application in which all PK's are GUID's - very easy to implement, no ID management issues, performance is great (main transaction table is now 3.5 million), the db is big but for $200 I can buy a disk that will be support the db for at least 10 years, all UI access to data is combo boxes and lists so no issue with typing

The only negative I see are that it could impact backup media size, eg maybe 40Gb DAT would have been ok but a GUID based database you may make you go to an 80Gb tape. Also, there is no doubt that when looking at the data while developing it is impossible to make sense of it without knocking up a view and linking the FK's to PK's and showing some sensible info from the Master table

A major advantage is that your database can go corporate without too much of a problem, eg merging the databases of divisional databases into a single database can be done without having PK clashes. This is why I really had to go that way for my database

Cheers, Peter
 
I tried what you stated and I got a type casting error "Cannot cast
System.String to System.Guid" I just passed the dataset to the dataadapter
which represents the Guid as a string. When I add a new row in a table in
the dataset I use this code:

Guid.NewGuid().ToString();

Thanks
 
Nevermind, I figured it out. You have to set the msdata to System.Guid:
msdata:DataType="System.Guid

Thanks
 
Back
Top