On Tue, Apr 22, 2014 at 12:05 PM, Simon Slavin <[email protected]> wrote: > On 22 Apr 2014, at 10:07am, Dominique Devienne <[email protected]> wrote: > Store them as 32 hex digits, or 32 hex digits with the minus signs in, or as > a 32-bit-length integer, I don't care, but have them conform to V1 or V4 > Algorithm generation, or something else mentioned on that page.
There's really no point wasting space to store a stringified 36-char GUID, rather than storing that same guid as 16-bytes. Which algo generated the GUID is embedded in the GUID itself, if it's standard conforming, and is irrelevant to relational integrity anyway. All RDBMSs can blob-to-hex if you want to see a dash-less hex GUID stored as a blob or RAW, and you can write something in whatever (C, PL/SQL, TSQL, pure SQL etc...) to splice the dashes in if you really want to. A guid is a guid, irrespective of its actual representation. And there's nothing wrong calling it as such. Store them as hex-encoded (or octal, or base-64, ...) text if that pleases you, but that doesn't make it any more or any less a GUID. --DD _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
