It might be true if you mostly store large quantities of NUMERICAL data
(float, int, ...) since they are currently stored as strings (the value
1234567, would be stored using at least 7-8 bytes instead of 4). If you
were in the same situation as I, where I use database mostly for
strings, you would be in the opposite situation, the SQLite database
would be about half the size of the MS Access one, since MS Access seems
to save all strings as UTF-16.


Simon B.



On Wed, 2004-04-07 at 10:50, Jakub Adamek wrote:

> Hello,
> 
> I am using SQLite in a car navigation system which should work on PDAs 
> as well. Thus speed and size is crucial for us. SQLite is superb in the 
> speed category, but the size of its file is not so superb. I see you 
> mentioned something about file size. My experience is that SQLite makes 
> roughly about 3x bigger files than MS Access. How would this change in 3.0?
> 
> Thanks for your excellent work,
> 
> Jakub Adamek
> 
> D. Richard Hipp wrote:
> 
> > A design proposal for SQLite version 3.0 can be found at:
> > 
> >     http://www.sqlite.org/prop2.html
> > 
> > Feedback from the user community is strongly encouraged.
> > An executive summary of the proposed changes follows:
> > 
> >    *  Support for UTF-16
> >    *  Better BLOB support
> >    *  User-defined collating sequences (for better
> >       internationalization support)
> >    *  Smaller and faster than 2.8.13.
> > 
> > The plan is to continue to support the 2.8.X series
> > indefinately and in parallel to the 3.X series.  But
> > the only changes to 2.8.X going forward will be bug
> > fixes.  New features will go into 3.X.  Beta releases
> > of version 3.X are expected within a few months.
> > 
> > I do not have much experience with UTF-16 and am
> > expecially interested in feedback on that area of
> > the design.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Reply via email to