> 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.
I totally agree. Because large objects exist aas separate file, this
was required, but after TOAST, the proper relational way should be used.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
