Dimitry Sibiryakov wrote:

>
>
>>It's absolutely necessary. A database serving as a content store for
>>a web application has to store jpeg, gifs, pngs, and who else knows
>>what else. Are you suggesting that a separate table or fields are
>>required for each image type? How does an application find the image
>>if it only knows it's name and not it's type?
>>
>>
>
> What application can do with an image of unknown type? The
>application can't even request right filtering because it doesn't
>know actual image type.
>

Are you asking about blobs stored without types or about types without
declared filter?

In either case there's not much the database can do for the
application. If you want the database to do something for you, it needs
to have to information to do it.

> In my dreams DB and the application should interact this way:
>Application has image of known type (let's jpeg). It says to
>database: "this chunk of bytes is BLOB sub_type -2. Store it into
>CONTENT field now!" Database (automatically) pick up filter for
>transmogrification sub_type -2 (which is indicated by app) into
>sub_type -1 (which is indicated in metadata by DB developer) and use
>it. The filter add a header to the chunk of bytes for future
>recognition of type and, say, pack it.
>

You are arguing that the type conversion should be performed when the
blob is stored rather than when it is fetched. I disagree. The
filtering process often results in loss of data. The different image
formats, for example, carry different attributes, so converting a jpeg
to a gif and back may loss attributes present in the jpeg format but not
in gif. Going the other way is worse, since jpeg using lossy
compression. This is true of document formats, squared. Turning a Word
document into html results in a massive loss of data. It is always
better to store the original blob in the database and converted to an
alternate version of retrieval.

I don't want to go too far in defending the historical blob filter
mechanism, however. It was designed before object oriented programming
was well understood and long before mime types were generally useful
(frankly, I had never heard of them). I think I might do something
quite different if I had to do it over again. Or, as in the case of
Netfrastructure, leave them out altogether (Netfrastructure has blobs
and clobs but no subtypes at all).