David Fetter wrote" <...> > > > This'd greatly simplify the > > cleanup-dead-objects problem, and we could avoid addressing the > > permissions problem at all, since regular SQL permissions on the table > > would serve fine. But it's not clear what regular SQL fetch and update > > behaviors should be like for such a thing. (Fetching or storing the > > whole blob value is right out, IMHO.) ISTR hearing of concepts roughly > > like this in other DBs --- does it ring a bell for anyone? > > Informix has some pretty good blob-handling: > > http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqlr.doc/sqlrmst101.htm >
Agreed. I used Informix a few years back in a system that scanned both sides of multi-page financial documents; we stored them in Informix' blobs, which IIRC could be tuned to be given number of bytes. We found that 90% of our images fit in a given size and since Informix raw disk access let them move up the whole blob in a single pass, it was quite fast, and gave us all the warmth and fuzziness of ACID functionality. But we didn't fetch parts of the BLOB -- metadata lived in its own table. There is/was an Illustra/Informix blade which let you in theory do some processing of images (indexing) but that seems like a very specialized case. Greg Williamson Senior DBA DigitalGlobe Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. (My corporate masters made me say this.)
