On 21 Dec 2010, at 12:16, Max Vlasov wrote: > Simon, I read both your suggestion and the Richard's good explanation about > network problems. I think that the idea still deserves to live in some form > :). I sometimes access sqlite db on a remote computer accessed with sqlite > shell executed in telnet/ssh. It works and it looks like good design for > interaction in terms of network bandwidth. If it can be implemented in more > friendly way toward the developer, I think it would still be a lighter > version of a sql-aware dbms than SQLite/PostgreSQL.
I would like to explore what is meant by 'lighter' in this context, and why it is desirable. I have thought about this in the context of what I think it might mean; if you mean it to mean something else please let me know. If it means that the on-disk stored data format (file size) should be as small as it is in SQLite today: -------------------------------------------------------------------------------------------------------- It should be significantly easier to define a new storage engine for MySQL that uses the SQLite data format for its tables. If it means that the client binary should be as small as it is in SQLite today: ------------------------------------------------------------------------------- At first glance there is some chance of improving matters. The MySQL client library is 3,251,266 bytes vs 752,924 bytes for SQLite on my Linux AMD64 machine. A cursory analysis suggests that it would be easier and as-effective to put the MySQL client on a diet. I unarchived the MySQL library to see what all the code in it is. Judging by the filenames 926,312 bytes is encryption/SSL code and 1,446,920 bytes is character-set conversion code. Subtracting the size of the encryption logic and all the character set logic except utf8 and ucs2 leaves 987,810 bytes for the MySQL client. Of course the connections would not then be secure; this is just for the sake of a fairer comparison: the corresponding SSL/encryption code would need to be added to any SQLite client library if its connections were to be meaningfully secured over a network. Actually a sensible halfway point would be to ditch everything but the strongest algorithms (keep AES, SHA-512, RSA and drop RC4, MD2, MD4, MD5, DES, BlowFish, TwoFish, etc). The real difference remaining is therefore about 235k, which I suspect is not worth fretting over on any device with a network connection. Building the MySQL client with -Os might even be enough to effect that change. > Another thought, imagine > that a remote computer contains many sqlite databases and moreover, many > versions of the same database. It's easy to imagine this like hierarchy of > sqlite files accessed remotely, but I just can't imagine straightforward way > to implement this with conventional client/server dbms. Implementing an SQLite-based server does not obviously enable this in and of itself. If you could open a database on a remote machine using its filename as the OP was trying to do it would enable this, but we got into this discussion when it was discovered that doing so was a bad idea. Best Regards, Phil Willoughby -- Managing Director, StrawberryCat Limited StrawberryCat Limited is registered in England and Wales with Company No. 7234809. The registered office address of StrawberryCat Limited is: 107 Morgan Le Fay Drive Eastleigh SO53 4JH _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
