Teg wrote:
Hello John,
You guys are both going off in you own directions and arguing
something that's really an unimportant implementation detail.
Serialization's a wonderful thing, if you need it. It's nothing more
than a protocol for storing, saving, transmitting something in a
format that can be re-constituted on the the other side by a reader.
It's useful, if you need it and solves problems some implementations
have.
I'd like to correct you a little. Serialization has nothing to do with
transmitting. Serialization is simply decompostion of some complex
arbitrary data (a struct instance) into something simple (sequence of
bytes, binary string, ...), and construction from bytes to complex data.
As for using base64 or hex encodings, why bother? SQLite is
perfectly happy with binary insertions using the newer parameterized
SQL compiling. I insert naked JPG files all day long with no encoding.
if your jpg files are represented as binary strings, then there's no
problem at all, put them as is. That make's no sence to convert data
back and forth between formats.
Inserting binary though doesn't solve the basic problem with
alignment and struct packing (which is only an issue in some cases),
serialization does solve this problem but, it may be a non-issue
depending on your implementation/CPU.
Sorry, there's no problem with inserting binary data in all cases.
Correct me if I'm wrong. (and what struct packing is related to placing
binary data into blobs??). perhaps, you mean binary data as a part of a
structure?
When your only tool is a hammer, all of your problems look like nails.
To me, a more fundamental question is why someone would want to save
structs to a database instead of to a flat disk file. I use a database
when I need to find something, not just to store things. For storage,
I just use the much faster naked disk I/O.
I didn't test it myself, but I strongly believe that it would be way
more efficient to search for an offset in already oppened file (that
might be sitting in ram) than ask the OS to search for a particular file
in it's file allocation table, then create os specific handle, do all
this back stage magic etc..., and at the end seeek to 0 offset. Off
course you may come with an example when having a separeta file would be
a better idea, but that's not the point here.
Suppose, you store users' avatars for some billboard. I think it would
be more efficient to ask sqlite to return JohnDoes123's pic as a 3-10Kb
blob, rather than asking for a filename where his pic is stored on hd,
and then reading this file. (imagine that there's no http or web server
involved with this billboard - just get the pic data)
