In my experience, store the blob information in a table to itself and do a
1:1 or 1:Many relationship between your main data and the blob data.

The reason for this is that SQLite will read the data of your request per
row if the query is asking for information past the field to which your
blob data lives.

So for example, off the cuff:

createTable Pikchurz(id:integer; Title:integer;Data:Blob;FileSize:integer);

If you do a [ select id,Title,FileSize from Pikchurz ], SQLite is going to
read Data.

The work around to this is keep Data as the last entry in your table
schema, or, use a different table that is directly related based on PK/FK

On Tue, May 8, 2018 at 9:08 AM, Mike Clark <> wrote:

>  Hi List!
> I'm developing a project that deals with image files and am considering
> storing all the images in the SQLite database itself, rather than (or in
> addition to) the file system.  Since the prospective users will probably be
> dealing with hundreds of gigabytes in their use of the project, I am
> wondering if this is an effective or efficient use of SQLite -- or safe,
> because of the risk of data corruption.
> I know the documentation says that SQLite can handle up to 140 TB (do we
> know of anyone who is doing this?), so hundreds of gigs is clearly doable.
> Is it advisable, however?
> ​(Sent this about 2 wks ago, but it never posted to the list and no
> moderator response either).​
> --
> Mike Clark
> Twitter: @Cyberherbalist
> Blog: Cyberherbalist's Blog <>
> ---------
> "Free will, though it makes evil possible, is also the only thing that
> makes possible any love or goodness or joy worth having."
> *- C. S. Lewis*
> _______________________________________________
> sqlite-users mailing list
sqlite-users mailing list

Reply via email to