Re: To BLOB Or Not To BLOB - Mailing list pgsql-general
From | Stephen Davies |
---|---|
Subject | Re: To BLOB Or Not To BLOB |
Date | |
Msg-id | 200004170842.SAA18786@mustang.sdc.com.au Whole thread Raw |
In response to | Re: To BLOB Or Not To BLOB ("John Henderson" <jrh@is.com.fj>) |
Responses |
Re: To BLOB Or Not To BLOB
Broken Links...Re: To BLOB Or Not To BLOB |
List | pgsql-general |
G'day. I do a lot of work with the BASIS textual/multi-media RDBMS package and run into this question all the time. There is one pretty basic answer: If you leave BLOBS lying around in the file system - particularly if it is a Novell etc file system - people move them and the links get broken. Just today I had an example where several thousand links broke because some dumb Novel administrator moved a directory holding files which were linked to from a database rather than stored in it. (Not my design decision) A database that can hold the BLOBS internally avoids this sort of snafu. (BASIS also has the advantage that it can automagically index almost any form of BLOB to the word/phrase/sentence level if it is stored in the database.) Cheers, Stephen Davies "John Henderson" <jrh@is.com.fj> wrote: > Hi, > It seems that the issue with large objects is "Why do you want the info in a > database?" > > It seems to me that the point of a database is its ability to order and > relate data. If you want to retrieve the "large-ish text files" based on > their content then I think you need to have the files in the database so > they can be searched. However, if you are going to retrieve the files based > on something about them that is stored as a separate attribute, such as > their title, then I think that storing the files as large objects is > unnecessary. > > If you have the option to "[do] as pointers t those files" then I think you > are not intending to use any of Postgres's features beyond its ability to > store and retrieve data. Surely the file system itself is 'better' at this > regardless of how stable Postgres LO's are. > > I would sure like to hear someone else's opinion on this because it seems > that quite a few folks are using large objects and I am often curious about > why. > > John Henderson > > >A while ago it was being held that the Postgres large object data type > >was too new and not sufficiently tested and mature to be used in a > >production environment. I am about to deploy a little database that > >involves storing large-ish text files (20-500k) which could be either done > >as large objects or as pointers to those files that would be then stored > >as ordinary files in the OS's filesystem. I am undecided as to this > >question. What are the pros and cons? What is the performance in either > >case vis-a-vis the other? It is a web app; the interface is done in PHP. > >Beginning from which version is the large object interface (if at all) > >to be considered stable and ready for production? > > > >cheers frank > > > >-- > >frank joerdens > > > >joerdens new media > >heinrich-roller str. 16/17 > >10405 berlin > >germany > > > >e: frank@joerdens.de > >t: +49 30 44055471 > >f: +49 30 44055475 > >h: http://www.joerdens.de > > > >pgp public key: http://www.joerdens.de/pgp/frank_joerdens.asc > > ======================================================================== Stephen Davies Consulting scldad@sdc.com.au Adelaide, South Australia. Voice: 08-8177 1595 Computing & Network solutions. Fax: 08-8177 0133
pgsql-general by date: