On Fri, Aug 04, 2000 at 07:55:52AM +0100, Peter Mount wrote:
> See below...
>
> Peter: I dissagree. There are dozens of instances where you would use a
> single BLOB but refer to it in more than one table. If you have a 1Mb blob
> refered to in 3 different tables, you don't want to store 3 instances of it.
> Say you were implementing some form of DIP system (Document Image
> Processing), then you only want one copy of the document stored, so that if
> that document changes, then every instance is changed.
>
But Peter, the relational way to avoid redundant storage should apply. For
every other type, one does this by storing the data in one place, with
a unique ID, and using the ID to refer to the data item, and joining when
you need the item itself.
So, once large data items are promoted to first class types, they should
act just like every other first class type. Otherwise, we violate the
principle of least surprise. Having software that tries to second guess
the developer is always frustrating.
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
