Universally Unique Identifier is an identifier standard used in software construction, standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE).
The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination.
Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. SOURCE: http://en.wikipedia.org/wiki/UUID
Is the native return val from this app level method a string(36): ie, a UUID in its canonical form: 550e8400-e29b-41d4-a716-446655440000 ?
I have not used these as Primary Keys before (I am used to Long Integers).
Are there any concerns using these as PK’s instead of Servoy sequences? I am thinking not via the Autoenter (since it is not one of the options here) but through say a Table Event (before Insert) and a Global Method that is passed the table name.
I am getting some “design pressure” towards managing remote laptops (without Internet connectivity) so I am re-thinking some of my PK design assumptions.
Those “remote laptops” are for sure a reason to reconsider the long integers. I am currently in the same process. I think the onInsert event is what I will go for, too (or a calculation).
I have also filed a feature request that Servoy will be able to fill pk columns with uuids (instead of Servoy sequence).
There is another great advantage of using uuids as primary keys: you can merge data from two or more database without ever having to think a second about your primary and foreign keys…
Thanks, Patrick … I think the add to the AutoEnter functionality would be a real plus too … hopefully Engineering will be able to schedule this in.
The UUID is a little heavier on index size etc but with modern hardware I am not really concerned considering the other emerging (at least in my thinking) benefits. I’m just at db model lockdown stage so easier to change now than later!
Do you know of any routines/plug-ins that will create/cast a binary representation of the longer ASCII string for the UUID’s? The string based UUID is quite long.
Less storage requirements for the index on the pk.
Even in very high row counts? Due to the high level of randomness in the strings, indexes will not be built (as efficiently) as say compared to integers or shorter binaries.
I am not speaking with a lot of experience in using a longer random string for a primary key so I am just kinda’ wondering/researching out loud. I know it is something I would rather not change a year or two from now on the current project
I noticed that Sybase stores the Binary(16) for its replication efforts, not the string itself: see http://www.sybase.com/detail?id=1027809 (see UUID section part way down the article). This, along with some other web articles I have read on indexes on UUID’s and hig row counts have left me wondering what is the best way to go. I am “working this through” … I really am not sure what is the best way to go.
Can you give an estimate? I really wouldn’t say this matters and if it does, then maybe you should consider OLAP or something else specialized for such loads of data.
Eventually + 1 million row count for sure (for OLTP).
OLAP demands will be offloaded to more appropriate structures for reporting queries and a data warehouse which can pull from multiple clusters and with better spindle counts (on a SAN/NAS) for the db engine.
My question is more to do with OLTP tables for routine transactional processing. I am just not used to such a long pk (not yet anyway ).
Ok. The amount you say will in my eyes be no problem at all. At least will it not make a difference if your primary key is a varchar(36) or an integer. I believe the difference is at most scientific.
Appreciated, Patrick. I came out of an Oracle shop at one time and this project is on Postgres … so I wasn’t sure (no slight on PG intended - it is a very technically sound engine).
Postgres could even take care of generating the keys for you as far as I know. Since this is not automatically cross database transferable, I can’t use it though. Seriously, I think that it is much safer for to go for uuids if you have replication in mind. And there is no downside except that these keys are almost meaningless to anyone (no comparison possible etc.).