>> In summary: the context of a GUID defines its "scope of required >> uniqueness," and a 16-byte GUID is essentially globally unique so long >> as >> it has no collisions within its context(s). (i.e. who cares if SHA1s >> collide, so long as it's not in the same repo?) > >You might be interested in UUIDs, which define the scope and provide >methods for presenting hashed, sequential and random GUIDs within that >scope: > ><http://en.wikipedia.org/wiki/Universally_unique_identifier> > >Libraries are available for many languages to generate UUIDs under many >of these schemes. > > >On 22 Apr 2014, at 6:57pm, RSmith <rsm...@rsweb.co.za> wrote: > >> Just to add - I cannot imagine why you would have dashes to start with > >Take, for example, this GUID: > >550e8400-e29b-41d4-a716-44de5544ac00 > >A program (or a TABLE) frequently handles many GUIDs which differ only in >one of the fields. For instance a program may have to represent a GUID >externally (on the screen and output files) with the complete GUID, but >it could store items internally (perhaps in a database) using only the >last 12 hex digits, or as an integer up to 2^48. Since it know that all >people GUIDs start > >550e8400-e29b-41d4-a716- > >whereas all vehicles GUIDs start > >550e8404-31e6-41d4-a716-
You don't ever really need a GUID at all. Simply use an "integer primary key" (an integer starting at 1) and simply pretend that it is being added to the applicable base GUID of your random choosing. Everything will still be unique and you will have saved yourself a crap load of storage space, index space, and conserved countless CPU cycles so that they can be spent on something more productive productive. I have never seen a need to actually use a GUID for anything, it is a ridiculous concept. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
