Adolfo:
I can't tell you how many times I felt a flat file approach would be
better. However, 2 years ago when the design began there was a
thought of 'Having the ability to mine data on the device would be an
invaluable tool'. SQLite has proven superb for some aspects of the
system, but not for
;
Sent: Wednesday, May 21, 2008 2:29 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] design question / discussion
Rich Rattanni wrote:>Hi I have a general design question. I have the
following senario...
>In an embedded system running linux 2.6.2x I have a sqlite database
>constantl
Rich Rattanni wrote:>Hi I have a general design question. I have the
following senario...
>In an embedded system running linux 2.6.2x I have a sqlite database
>constantly being updated with data acquired by the system. I cant
>lose data (hence why I am using sqlite in the first place). However
> It seems unclear to me what your requirements are trying to attempt.
>
> Do you need to keep any of this data, if so for how long?
I have to keep all data until a download. Downloads can fail too
so I cannot delete data until a download succeeds.
> Do you need to be able to read the older
I think your trying to overcome the read/write concurrency issue with sqlite
correct? You want to have the ability to copy data (ie ftp) and recieve new
data into an overflow database.
Main.db = contains download.db and is an attachment point for ancillary db's.
wrtdb_###.db = Always write
> Perhaps i've missed something or don't understand it well. Your
> databases is all on the same file or do you have 2 separate sqlite
> sessions to 2 different databases files? In the first scenario you
> must be very fast and in the second you can switch from one database
> to the other, unbind
At 19:12 20/05/2008, you wrote:
>Actually my reason for writing into a seperate database is more...
>well crude. I tar several databases together then encrypt using
>openSSL. Then an FTP like program transmits the data a central server.
> I must suspend writing into the database for the duration
Actually my reason for writing into a seperate database is more...
well crude. I tar several databases together then encrypt using
openSSL. Then an FTP like program transmits the data a central server.
I must suspend writing into the database for the duration of the tar
operation since tar does
Rich,
>From your design it appears you are writing to a seperate db while a
>"download" is happening? I'm guessing that is to prevent a read/write lock
>contention correct?
It seems to me that any new data coming in will need to write and you are
simply looking to read during a download
Thanks for your reply. I have done some quick timing tests on my
system; a vacuum can take 5 or more minutes (synchronous full), and a
delete and recreate is rougly 3 seconds. I think I did such a test
with a 30MB database. The database resides on a jffs2 file system
(compression off), which
> Hi I have a general design question. I have the following senario...
IMHO your design sound reasonable. In relation with the vacuum question
I suggest try to delete and re-create each table and watch both timings.
HTH
Adolfo
___
sqlite-users
Hi I have a general design question. I have the following senario...
In an embedded system running linux 2.6.2x I have a sqlite database
constantly being updated with data acquired by the system. I cant
lose data (hence why I am using sqlite in the first place). However
periodically I have
12 matches
Mail list logo
