Re: pg_dump/restore to convert BLOBs to LZTEXT (optiona l!)
От | Bruce Momjian |
---|---|
Тема | Re: pg_dump/restore to convert BLOBs to LZTEXT (optiona l!) |
Дата | |
Msg-id | 200008041547.LAA15160@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump/restore to convert BLOBs to LZTEXT (optiona l!) ("Ross J. Reedstrom" <reedstrm@rice.edu>) |
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: