><snip>
>>-Performance is a myhth. I haven't yet seen something showing GUIDs perform worse.
>>-If your concern is space yes you might be right, it's 16 bytes. Twice of bigint and 4 times of integer. But then think XML. It's used a lot in .Net and it has a lot redundancy in itself. You can live with it:)
>>If you can search about it here on UT there are some long running threads. Also google "identity crisis".
>>Cetin
>
>Thanks again for your thoughts (and borrowed thoughts <s>)
>
>I am glad to see your statement that GUIDs have relative poor performance. I have been searching the internet for statistics showing that performance is degraded when choosing a GUID as PK compared to (big)int as PK. I hope someone can give me such link (unless is is infact just a myth).
>
>I do not feel space is an issue (I used to think it was an issue about 9 months ago). Disk space is cheep and unlimited (well almost <s>). Now something that I didn't think of (Bonnie brought it to my attention) is bandwidth. I have not yet made up my mind if I think that is a major issue or not (I am searching the web for that too).
>
>Einar
Did I really say GUIDs perform poor/worse? If I did I didn't mean it:) There are interesting tests by SQL gurus (and how I know they're gurus - their code sounded to be much better than mine:) on internet. I couldn't find my favorite but found this one for example:
http://www.sql-server-performance.com/zn_guid_performance.aspIt starts with almost the same statements who against GUIDs say:) But read conclusion part carefully and check getdate() results (getdate() is a technique to scrub GUID to be sequential - once upon a time there were no NewSequentialID() in SQL server) If you insert 4million rows everyday than that makes a difference - 400secs more time so right, it's not a myth, GUIDs are slow:)
PS: Bandwith? What bandwidth? You can fit thousands of rows to your bandwidth and think about extra 8*thousands or 12*thousands bytes?
Cetin
