convert guid to integer

[jcaulder]

We have primary keys defined throughout our system as GUIDs(uniqueidentifiers) in SQL Server. Some of this data is synchronized to low memory handheld devices. The handheld device runs a custom written .NET application.

The problem is that the GUIDs are taking up a huge amount of space because of their size(16 bytes each). A row in a table may have a primary GUID key as well as four foreign key GUIDs. Multiply this by many rows and you quickly eat up a lot of resources on a handheld.

Since long integer types take only 8 bytes, is it possible to convert the 16 byte HEX GUID to long integer or some other type that could possibly cut the memory usage in half?

It would not appear converting it to byte array has any advantage because it still would end up as 16 bytes right?

I'm sure there is some common method of doing this?

TIA!

J

 

[chiph]

If the conversion is only one-way (guid to integer, and not back again) you can run it through a hash function (see System.Security.Cryptography).

If you need to round-trip the info, you can't do it as an integer. Your best choice then would be to promote it to a higher dimension representation. Instead of base-16 (GUIDs are hex values), store them in base-62 (A..Z plus a..z plus 0..9) and the memory requirements will be reduced somewhat.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[chrissie1]

Actually when you have your DAL on the server and the machines get their infomation from the server then your bussines objects for the CE machine and all the other machines don't really need the GUID. Nut if you really really need them then go for chiph's suggestion.

Christiaan Baes
Belgium

"My old site" - Me

 

[jcaulder]

Ok, thanks for the info guys.

The conversion must go both ways. After thinking about it, there was no way an integer could work since there are a plethora of combinations of hex values in a GUID that could lead to the same integer value right?

The GUIDs must be on the handhelds because data rows are created there. The new rows have several foreign keys that are all GUIDs that relate the new row to, among other things, a rate table(for charges), a vendor table, an associate table, etc. Each of these foreign keys are selected by the user on the handheld(via dropdowns).

I will investigate base 62 as an option.

Thanks!