Thanks for the quick reply, Simon. I was rather hoping there might be some efficiency tweaks I can do to the db file (e.g. more explicit creation statements, or postprocessing) instead of getting into custom sqlite builds.
I was on the bus when I wrote my earlier mail but at home now I've tried VACUUM. Unfortunately it only shaves ~250KB off the ~41MB database. Open to other ideas? Can I limit possible string lengths for the TEXT fields or is it already using VARCHAR internally? If so, any idea where all the space is being used? Can I profile the tables to learn how much data they hold individually or the efficiency of that storage? L On 5 March 2012 19:53, Simon Slavin <slav...@bigfraud.org> wrote: > > On 5 Mar 2012, at 10:59am, Larry Knibb <larry.kn...@gmail.com> wrote: > >> I'm developing a mobile application which downloads my database so smallest >> possible database size (i.e. on-disk/footprint) is important. >> >> Currently my database is 41.5MB with indexes and to reduce the download I'm >> zipping it with max. compression Deflate down to 18.4MB. >> >> I noticed I can get it down to 12.1MB using LZMA compression but >> unfortunately there's no LZMA library for Windows Phone yet... but anyway. > > Would this be useful ? I think you might have to be using the SQLite API > calls rather than a third-party extra layer. > > <http://www.hwaci.com/sw/sqlite/cerod.html> > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
