Subject | Re: [firebird-support] Storing images. |
---|---|
Author | Ann W. Harrison |
Post date | 2005-01-06T16:40:24Z |
Adrian Wreyford wrote:
loose significant information, then by all means, restrict the size. If
there's good reason to use large jpegs, go ahead.
few image types for permanent inclusion - not that we'll do anything
with them necessarily, but jpeg has become common enough that tools
might be able to use the type to offer jpeg rendering automatically.
Ann
>That's really an application issue. If it's convenient and you won't
> A few more questions:
> 1). Should I be limiting the size of the jpeg image the end user is storing?
loose significant information, then by all means, restrict the size. If
there's good reason to use large jpegs, go ahead.
> 2). Should I use a negative Sub-Type for the Blob, or BLOB SUB_TYPE 0?I'd pick a negative subtype and lobby for the Firebird group to define a
few image types for permanent inclusion - not that we'll do anything
with them necessarily, but jpeg has become common enough that tools
might be able to use the type to offer jpeg rendering automatically.
> 3). Would you recommend I store these blobs in the same database as all myYes, store them in the same database. Cross-database work is a nuisance.
> other data, or in a second database? (Probably doesn't matter).
> 5). What I will do to speed up browsing, is add a toggle under my programSounds good.
> preferences to display or not display images, thus the server does not have
> to pass the BLOB data, speeding up scrolling quite substantially, and I
> tried this, and it works well .. comment please?
Ann