Re: Re[4]: [sqlite] reg:blob data reading

2006-09-18 Thread Thomas . L 
On Mon, 18 Sep 2006 10:20:36 -0400, you wrote:

>There's no right or wrong way.

There is viewpoint from June 2006 with title: 
   "To BLOB or Not To BLOB:
Large Object Storage in a Database or a Filesystem?"

at
http://research.microsoft.com/research/pubs/view.aspx?type=technical%20report=1089

Maybe it turns a light on... ;-)


Best Regards
Thomas

www.thlu.de

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: Re[4]: [sqlite] reg:blob data reading

2006-09-18 Thread Jay Sprenkle 

On 9/18/06, Teg <[EMAIL PROTECTED]> wrote:

Hello Jay,

There's no right or wrong way. I was just suggesting that there are
cases where you want to store the whole file in the DB. I have an
application that generates 1000's of 150K compressed files. I've been
toying with the idea of shoving them all onto a DB because of the way
Windows groans when you have to enumerate folders with many small
files.


The scanner I use takes care of that by making a directory for each
batch of documents scanned. I've seen that same thing on Windows
systems for other projects. I ended up having to create a manager that would
store files into numbered sub directories to avoid it.


The downside of course is I'd have to vacuum the tables from time to
time.


That's why we get paid the 'big bucks'   ;)

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re[4]: [sqlite] reg:blob data reading

2006-09-18 Thread Teg 
Hello Jay,

Monday, September 18, 2006, 10:05:19 AM, you wrote:

JS> On 9/18/06, Teg <[EMAIL PROTECTED]> wrote:
>> Hello Jay,
>>
>> The whole reason I store files in the DB in the first place is to have
>> a single "package" to move around and backup when needed. My
>> application is storing whole series of PNG and JPG files in the
>> DB with meta data describing where the images came from.

JS> My technique won't help you then. I use it for things like scanning images
JS> of documents and using the database to keep track of the documents.
JS> I never have to search a picture using a select statement so it would
JS> be silly for me to put them into the database. I just back up the file
JS> system using off the shelf backup software and it works fine.

JS> --
JS> SqliteImporter and SqliteReplicator: Command line utilities for Sqlite
JS> http://www.reddawn.net/~jsprenkl/Sqlite

JS> Cthulhu Bucks!
JS> http://www.cthulhubucks.com

JS> 
-
JS> To unsubscribe, send email to [EMAIL PROTECTED]
JS> 
-


There's no right or wrong way. I was just suggesting that there are
cases where you want to store the whole file in the DB. I have an
application that generates 1000's of 150K compressed files. I've been
toying with the idea of shoving them all onto a DB because of the way
Windows groans when you have to enumerate folders with many small
files.

In the case of these small files, performance is dominated by
enumerating and decompressing so, even if it's a bit slower selecting
the files out of the DB, any improvement in enumeration speed would make
a noticeable performance boost.

The downside of course is I'd have to vacuum the tables from time to
time.

-- 
Best regards,
 Tegmailto:[EMAIL PROTECTED]


-
To unsubscribe, send email to [EMAIL PROTECTED]
-