Coverting Guid to string

Question

I am creating a application and I wanted to try and use GUIDs. I am using Entity Framework code first and LINQ so I thought the easiest way would be to use

string guid = Guid.NewGuid().ToString();
var acc = new v_Account();   
acc.v_AcctGuid = guid;

And then store my GUIDs as type string in my database. Is this a bad practice? Is a GUID really just a globally unique randomly generated string potentially?

I am pretty sure it is going to work but I just don't want to face problems down the road or create a vulnerability by doing this.

http://stackoverflow.com/questions/467271/how-random-is-system-guid-newguid ...'How Random is a Guid'? ...Although, why don't you just have an incrementing integer for their AccountNumber...why does it need to be a Guid? — Arran, Mar 27 '13 at 13:04
Why are you converting GUID values to strings instead of just using them directly, i.e. defining the `v_AcctGuid` property as type `Guid`? — Daniel Pratt, Mar 27 '13 at 13:06
I would recommend reading up on `GUID` also hopefully you are not going to use this as a potential `Primary Key` `Integer values are much quicker when Indexing off of than Strings` GUIDS are said to be `Unique` I don't think that you have the time to even test the accuracy of if a GUID would ever repeat itself...I would recommend doing some more research before you put in too much `Wasted Effort` — MethodMan, Mar 27 '13 at 13:07
A GUID is really an array of 16 bytes. It's merely represented as a hex string and broken into parts to make it a bit more human usable. But at the end of the day all it is is 16 bytes and it's best to store it as the byte array instead of a string, as the byte array will take up half as much space. MS SQL Server actually has a GUID column type, if you're using that. — Pete, Mar 27 '13 at 13:08
You're not saying what you are going to do with the GUIDs so we can't tell you whether it's dangerous or not. GUIDs are just a piece of data. Everybody's guess is that you want to use them as unique values for Primary Keys; that would be a bad use of GUIDs. Use your database's facilities for Identity fields. If you are trying to use them for something else, please explain. — Euro Micelli, Mar 27 '13 at 13:31

score 6 · Accepted Answer · answered Mar 27 '13 at 13:07

6

A GUID maps directly to a MSSQL database as a uniqueidentifier type. So there is no need to stringify it.

Just use it directly:

acc.v_AcctGuid = Guid.NewGuid();

Assuming:

public class Account
{
    public Guid v_AcctGuid { get; set; }
}

answered Mar 27 '13 at 13:07

Davin Tryon

66,517
15
143
132

what if he doesn't use MSSQL? What if the db he uses doesn't support GUIDs? – dutzu Mar 27 '13 at 13:09
1

@dutzu that is why I mention the database in my answer. Also, most people using EF are using MSSQL. – Davin Tryon Mar 27 '13 at 13:10
1

`dutzu` its the same thing in `Sql Server` that's like asking what if the DB he's using doesn't support a `string` come on now... `Dutzu` here is some good brush up reading to answer your questions / comments http://www.dailycoding.com/Posts/generate_new_guid_uniqueidentifier_in_sql_server.aspx – MethodMan Mar 27 '13 at 13:11

score 1 · Answer 2 · answered Mar 27 '13 at 13:08

If the db you are targeting does not support GUIDs (like SQLite for instance) then it's ok to store as string and then expose them to the Business Layer as GUID making the necessary conversions on the getter and setter of a property of type GUID that masks the string property of the entity.

Coverting Guid to string

2 Answers2