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
