Your BLOBs are big for rapid access as linked stored pages in an RDBMS.
Individual files give processing advantages but have the downside of
not being just one file like Sqlite.
Design an experiment. You will find the balance between simplicity and
speed which suits your application.
Dimitris Servis wrote:
Hello John,
thanks for the valuable piece of advice. The idea is that either
1) I store data in tabular form and work with them
2) I create a table of blobs and each blob is the binary content of a file
(2) is my method in question, for (1) we all know it works. So I turned to
SQLite just because it seems that it is a lighweight single file database.
So, even if i don't like (2), I can setup an implementation where I have a
file system inside a fully portable file.
BR
dimitris
2007/3/18, John Stanton <[EMAIL PROTECTED]>:
A word of warning if you use the traditional method, an RDBMS table with
descriptive data and a reference to the name of the file storing the
binary data. If you store a lot of files in a directory you can get
into trouble. A robust design uses some form of tree structure of
directories to limit the size of individual directories to a value which
the system utilities can handle.
It is very tedious to discover that "ls" does not work on your directory!
Martin Jenkins wrote:
> Dimitris P. Servis wrote:
>
>> I have to provide evidence that such an anorthodox solution is also
>> feasible
>
>
> If it was me I'd "investigate" the problem by doing the "right"
thing in
> the first place, by which time I'd know enough to knock up the "wrong"
> solution for the doubters before presenting the "proper" solution as a
> fait accompli.
>
>> I have to compare access performance with flat binary files
>
>
> If I remember correctly, there's no random access to BLOBs so all you'd
> be doing is storing a chunk of data and reading the whole lot back. I
> don't think that's a realistic test - the time it takes SQLite to find
> the pages/data will be a tiny fraction of the time it will take to read
> that data off the disk. You can't compare performance against reading
> "records" out of the flat file because "they" won't let you do that. In
> all it doesn't sound very scientific. ;)
>
> Martin
>
>
-----------------------------------------------------------------------------
>
> To unsubscribe, send email to [EMAIL PROTECTED]
>
-----------------------------------------------------------------------------
>
>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
