> All BLOBs are stored inline. The only complication comes when the total row length is longer than a page.
Ok thanks! That is besides my original question but what is the complication in that case? Is the blob partially stored in the row, or is some indirection to other pages used, with only some pointer stored in the row? > Surely you mean big-endian? Yes, my mistake :) > Storing Blobs has a few conversions added if you try to use the SQL to store it, but it's quite efficient when using the API. By "use SQL", you mean as a literal blob embedded in the SQL string? My main use case would be through the API, the actual numbers are fixed precision, and so scattered over the range they cannot be displayed to end users without using exponents, so some formatting will have to happen. Besides size, using a blob rather than base32/base64 would simplify the encoding/decoding, and for debugging, blobs usually display in an hexadecimal form here, so a big-endian blob would be directly "readable". On Wed, Mar 2, 2016 at 11:07 PM, Doug Currie <doug.currie at gmail.com> wrote: > On Wed, Mar 2, 2016 at 4:42 PM, R Smith <rsmith at rsweb.co.za> wrote: > > > > > > Personally, unless your space is constrained, I would simply save the > > numbers as strings, perhaps Hex or BCD with leading chars and convert as > > needed. This would sort correctly without tricks and not do much worse > for > > space. (Base64 would be even better space-wise but won't sort correct). > > > > There is an encoding defined in RFC 4648 "Base-N Encodings" that does > preserve sort order; it is called Base 32 Encoding with Extended Hex > Alphabet. I would think the Base64 alphabet could be rearranged to have the > same property. > > e > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
