The possibility of having to merge data from several independent test stations is what made me think of using GUID in the first place. I don't think there's a better way.
As for wasted space, the few extra bytes needed by GUID is a drop in the bucket compared to the blobs I'm storing. If I was sure I wouldn't be merging data I might use timer ticks as my ID, but I'm not sure and I can't take the chance. -Bill > -----Original Message----- > From: [email protected] [mailto:sqlite-users- > [email protected]] On Behalf Of Stephan Beal > Sent: Wednesday, April 23, 2014 11:51 AM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] BLOBs and NULLs > > On Wed, Apr 23, 2014 at 6:56 AM, Keith Medcalf <[email protected]> > wrote: > > > 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. > > > > Until one implements a DCVS (i.e. Fossil), at which point sequential > numbers become literally impossible to generate. > > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct > of those who insist on a perfect world, freedom will have to do." -- > Bigby Wolf _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any attachments are solely for the use of the addressee and may contain information that is privileged or confidential. Any disclosure, use or distribution of the information contained herein is prohibited. In the event this e-mail contains technical data within the definition of the International Traffic in Arms Regulations or Export Administration Regulations, it is subject to the export control laws of the U.S.Government. The recipient should check this e-mail and any attachments for the presence of viruses as L-3 does not accept any liability associated with the transmission of this e-mail. If you have received this communication in error, please notify the sender by reply e-mail and immediately delete this message and any attachments. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
