How are you populating your Entity ID fields?

Question

Just curious as to how people here are coming up with IDs for entities. 

For example, if you're storing contacts as separate Entities within a Container, what do you use? 

 - If I use any personal info about the contact, it may change or may be a typo and the ID field cannot be changed, so I wouldn't want to lock that typo in place. 

 - If I use an integer based ID, how would I know what the next ID is if an ID is already in use? I assume I would have to query the service.  Seems rather inefficient.

 - Then there are GUIDs... are there inefficiencies for using a GUID for the ID field, or other reasons I might want to consider something else?

Thanks,
David

Answer 1

Shortly after posting this I found Dave's response to the "Foreign Key" thread that says...
 

Right now I use DateTime.UTCNow.Ticks to create a unqiue value for s:Id. I also worked up a pattern that uses the difference between the current date time and some (far out) future date as a way to create a *descending* order pattern where the most recent entries always appear at the top.

I like this better than a straight GUID.  Care to share an example of what you use?  Do you append any sort of random string after that ? (Maybe... 20080703.1611.3211.eoaisvnf...  just to make sure?)

Any other ideas?

Thanks,
David

Answer 2

You might want to put a little bit more thought into coming up with IDs than using GUIDs.  If you remember, SSDS returns entities ordered by ID.  Knowing what your IDs are and making sure they aren't random can help you in a number of cases.  In Dave's example, he tries to ensure that the more recent entries get returned first.  You can also use your knowledge of IDs to have multiple threads retrieving the data.  For example, if you use integers as IDs, you can have one thread retrieve the first N entities, the second thread the next N, and so on.

Stan

---

Program Manager, Cloud DB

Answer 3

David:

I think I was the author of the reply you mentioned (only to accept any blame, not take credit [grin]).

I use a class that derives from  Stopwatch (which is a bit more accurate).  I'm finishing up a new example app that uses the same code to generate Ascending and Descending keys.  I'll post the code later today and will include the snippet here in this thread (once i get back to the office to access the source code).

MikeA

---

Mike Amundsen [http://amundsen.com/blog/]

Answer 4

Stan,

Regarding using integers as IDs... 

From what I've read so far, you would have to query a container and then loop (if there's more than 500) just to find the next integer to use.  

Then, if you have a couple of different applications adding entities to the same container, there's a potential for conflict.  Supposing this worked without conflict, it still seems rather inefficient, no?

Unless I'm missing something obvious... which is more than likely.

Thanks,
David

Answer 5

Honest question...

Is generating your own ID's that much of a pain?

Answer 6

generating IDs is no pain as long as you allow a client or a proxy to do the work. in the case of clients, you will need assurance that multiple clients running at the same time will never create identical IDs.

GUIDs do a good job at that, but are a non-starter as SSDS uses the s:Id for sorting and offers no other sorting option.

MikeA

---

Mike Amundsen [http://amundsen.com/blog/]

Answer 7

Here's the code snippet from my SSDS HTTP Proxy that generates ascending or descending Ids:

1	private string MakeAscendingId()
2	{
3	DateTimePrecise dtp = new DateTimePrecise(10);
4	DateTime dt = dtp.UtcNow;
5	return dt.Ticks.ToString();
6	}
7
8	private string MakeDescendingId()
9	{
10	DateTimePrecise dtp = new DateTimePrecise(10);
11	DateTime future = new DateTime(2100, 1, 1, 0, 0, 1);
12	return Convert.ToString(future.Ticks - dtp.UtcNow.Ticks);
13	}
14

This code uses a custom class (DateTimePrecise) by James Brock. Here's the details on how to get his code:

/// DateTimePrecise class in C# -- an improvement to DateTime.Now

/// By jamesdbrock

/// http://www.codeproject.com/KB/cs/DateTimePrecise.aspx

/// Licensed via The Code Project Open License (CPOL) 1.02

/// http://www.codeproject.com/info/cpol10.aspx

///

/// DateTimePrecise provides a way to get a DateTime that exhibits the

/// relative precision of

/// System.Diagnostics.Stopwatch, and the absolute accuracy of DateTime.Now.

I'll be posting my complete sample app that uses there routines shortly and will update the list here w/ details.

MikeA

---

Mike Amundsen [http://amundsen.com/blog/]

Answer 8

Q:  "Is generating your own ID's that much of a pain?"

I'm only now making my very first SSDS "test" application.  

I'm not a DBA, so I know enough about database best practices to make myself dangerous.  And, when the model is completely changed, like is happening with SSDS, I know that these best practices change too.  If others have already thought about how IDs might affect performance, programmability or some other aspect I haven't thought of... I'd love to leach off of that knowledge.  I know that brainiacs put a lot of time and effort into things even more mundane than what is the best type of ID to use in a database... and I'd like to leverage that.

Also, as Mike points out, if I have multiple clients and I'm creating integer IDs, a conflict is a very real possibility... something I never had to think about with SQL Server.

Mike, thanks for snippets.

Answer 9

Agreed, I am just always looking for feedback. A great deal of these items are on our list of "Things to do". I want to ensure that we provide the most requested features first. That is why you will typically see me asking questions such as this.

-Dave

Answer 10

Dave:

FWIW, getting SSDS to create unique IDs is not high on my "wish list" right now.  I understand where you are coming from on this and am OK with the current behavior on generating IDs.

Sorting is a biggie for me as is a "more records" flag when i get my first 500. Also being able to change the "page" size (100, 50, default=500, etc.) is high on my list.

Thanks for listenin'

---

Mike Amundsen [http://amundsen.com/blog/]

Answer 11

Mike,

I wouldn't say that unique IDs are high on my "wish list" either... it's just one of the first things that I'm naturally running into while introducing myself to SSDS, so I thought I'd see what the consensus was.

Answer 12

I'm using a Kind (usually abbreviated) prefix, underscore, and ascending integer starting with 10000001.

See the second image at Mike Amundsen Posts Sample SQL Server Data Services Provisioning Application.

However, I'd appreciate the option to specify a bigint identity field.

---

--rj (OakLeaf Blog)

Answer 13

Roger, how are you determining the next integer to use?  I'm assuming you must have a single instance client that stores these internally instead of querying the cloud each time?

Answer 14

It is harder to maintain sequential IDs when multiple clients can access the same container. (e.g. if I use integer as ID, how to make sure the integer IDs never conflict, and always in sequence? If I use DateTime, can I trust the Client side DateTime is always accurate?) 

If SSDS offers GETDATE() which I can use for EntityId then it should solve the problem for me............any thought on using GETDATE() as Id?

Answer 15

If SSDS offers GETDATE() which I can use for EntityId then it should solve the problem for me............any thought on using GETDATE() as Id?

Not today is doesn't, but like I said previously, I am trying to gauge the level of urgency for this and any possible workarounds in the interim

-Dave