RE: [sqlite] IO Access Time
Using an SQL engine to drive a relatively small database is not really very simple, IMHO. But you will notice I am a member of the SQLite fan club for some time now. My largest dataset is somewhere just over 10K rows. I justify using SQLite by noting the advantage of using a well maintained, widely used, small footprint, database which allows me to use a well implemented "standard" data access language (read superior transportability). These advantages (read superior transportability) provide great value over my previous data management systems. Remember ISAM, Paradox, xBase, and etc.? Some of my stuff running today "grew up" on some pretty archaic technology. With each "upgrade" I noticed the things supporting SQL provided a much easier path than those that did not. Now, if it don't do no sten'ken SQL, it is toast! Fred > -Original Message- > From: John Stanton [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 01, 2006 12:29 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] IO Access Time > > > [EMAIL PROTECTED] wrote: > > John Stanton <[EMAIL PROTECTED]> wrote: > > > >>Sqlite is more than one flat file. It is impossible for it > to use less > >>resources than one flat file. > >> > > > > > > I guess this depends on the format and content of the flat file. > > > > As an experiment, I constructed a database with 16K rows with each > > row containing 3 random integers. The flat file (ascii text) was > > 999KB. The SQLite database was 566KB. So in this one case, at > > least, the SQLite database is smaller than the flat file. > > > > Without additional information on your flat file format, I would > > think it was likely that the flat file is smaller than the > > SQLite database. But it is not impossible for an SQLite database > > to be smaller. > > -- > > D. Richard Hipp <[EMAIL PROTECTED]> > > > However if you stored your data as binary integers your flat > file with > 16K records would take 192K of 32 bit words and 384K of 64 > bit and each > record would be accessed very fast. > > If the data in this small set were to be addressed by content > a string > search would also be very fast and make indexing of little value. > > "Everything should be made as simple as possible, but not simpler". > ~Albert Einstein
Re: [sqlite] IO Access Time
John Stanton <[EMAIL PROTECTED]> wrote: > > Sqlite is more than one flat file. It is impossible for it to use less > resources than one flat file. > I guess this depends on the format and content of the flat file. As an experiment, I constructed a database with 16K rows with each row containing 3 random integers. The flat file (ascii text) was 999KB. The SQLite database was 566KB. So in this one case, at least, the SQLite database is smaller than the flat file. Without additional information on your flat file format, I would think it was likely that the flat file is smaller than the SQLite database. But it is not impossible for an SQLite database to be smaller. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] IO Access Time
Christian Smith wrote: John Stanton uttered: In general you must expect Sqlite to use more of all resources compared to a flat file. After all Sqlite is a flat file with additional logic. Except updates and selective reads will be cheaper in general, as less IO is required due to additional logic. Storage will go up, however. SQLite trades CPU cycles for IO compared to flat file access. Christian Sqlite is more than one flat file. It is impossible for it to use less resources than one flat file. The only advantage you would gain from Sqlite is in the case where you use the flat file inefficiently. Sqlite is useful when you want data management and SQL access implemented in a very elegant and simple way. -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
Re: [sqlite] IO Access Time
John Stanton uttered: In general you must expect Sqlite to use more of all resources compared to a flat file. After all Sqlite is a flat file with additional logic. Except updates and selective reads will be cheaper in general, as less IO is required due to additional logic. Storage will go up, however. SQLite trades CPU cycles for IO compared to flat file access. Christian -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
Re: [sqlite] IO Access Time
Aseem Rastogi wrote: Hi All, I am planning to migrate to SQLite for my embedded system application. Currently we have a flat text file which we read and write using normal C++ routines. Whole of the configuration is written everytime some change happens. We do it using ofstream. For reading any object, we keep all the objects in memory and return from there (to prevent file read every time). This takes up a lot of memory but makes it faster. I am a bit concerned about following issues while upgrading to SQLite : 1. How does SQLite behave as compared to our current approach regarding I/O access time ? 2. How much disk space does SQLite take as compared to flat text file ? If somebody has some benchmarking data for these issues, it will be really helpful if he can enlighten me on this. Thanks in advance, Regards, Aseem. In general you must expect Sqlite to use more of all resources compared to a flat file. After all Sqlite is a flat file with additional logic.
Re: [sqlite] IO Access Time
On 8/1/06, Aseem Rastogi <[EMAIL PROTECTED]> wrote: 1. How does SQLite behave as compared to our current approach regarding I/O access time ? 2. How much disk space does SQLite take as compared to flat text file ? If somebody has some benchmarking data for these issues, it will be really helpful if he can enlighten me on this. You could test these issues using the command line program provided with sqlite in a few minutes.
