Cool. So it's treating each 2 digit pair as a single byte hex value, but what does blob do with the dashes?
-----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Dominique Devienne Sent: Tuesday, April 22, 2014 11:55 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] BLOBs and NULLs On Tue, Apr 22, 2014 at 5:35 PM, Drago, William @ MWG - NARDAEAST <william.dr...@l-3com.com> wrote: >>I myself prefer create table foo (guid blob primary key [NOT NULL], ...). > > If a genuine GUID looks like this: 37af1247-2e77-4880-8f46-48803ae2cd0a, then > why blob and not text? Simply because of the extra space needed to store it. 36 bytes vs 16 bytes. That's 20 wasted bytes for the PK, and everytime that PK is references in other tables' FKs too. Times millions of rows, it adds up, for nothing. The GUID is no less "genuine" as you put it, just because it's stored as a 16-bytes blob rather than the canonical 36-char text preferred by humans. The native code guids, e.g. boost::uuid, also use 16 bytes, so conversions to/from the DB (binding/defining) would required bytes-to-text, and text-to-byte conversions, again for no gain. If we ever show a GUID to the user, which is rather rare (and often a bug), sure, we pretty-print it as dash-separated hex, but otherwise the most compact "native" representation is used everywhere else. For ad-hoc queries using the shell-tool, SQLite's x'ff' blob-literal comes in handy too, and quote() [1] is used for blob-to-hex conversions in selects (nothing needed in blob-to-blob joins). --DD [1] http://stackoverflow.com/questions/1039461/how-to-display-blob-value-using-xabc-binary-string-literal-syntax _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org 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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
