>>>>>>>>What is the need for randomness? Not clear from the post. Why not ask the server for a unique ID if GUID is considered too flakey?
>>>>>>>
>>>>>>>Don't think GUIDs are flaky (at least compared to other options). If you ask a server to generate an ID (what are you suggesting? An int?) you have problems with overlapping hits......
>>>>>>
>>>>>>calling into DB table, creating records with candidate key, perhaps with some rules invalidating to stem growth without prune
>>>>>
>>>>>But why bother ?
>>>>
>>>>There are a couple of UC where the device / endpoint making changes has to be logged as well. -If/When the ID of the device has to enter the "DB space", the mechanics of the DB might be used again. Embolded part of my original post does not imply I think GUID is especially untrustworthy, but if there are very demanding specs I'd trust a DB based ID generating mechanism more.
>>>
>>>But, to be safe, the table issuing Ids would need to be locked on each request. That means multiple requests would essentially be handled in a serial fashion - bit of a bottle neck on a web server ?
>>
>>If the server bottlenecks measurably creating new records with candidate ID's the whole project is in trouble if adding info is in the specs ;-))
>
>Exactly. So why not use GUIDs ?

Supposing this is for a project where client can create records, I would argue for a consistent handling of "new/create", not against GUID in general. Client GUID is lots easier, but besides key length SOMETIMES leads to bad DB performance (most of the times where bad performance could be eliminated the GUIDs were created/modified on the server). Also the minimal duplicate key risc might have different priorities depending on use case and/or customer.