Re: To BLOB Or Not To BLOB
От | Thomas O'Dowd |
---|---|
Тема | Re: To BLOB Or Not To BLOB |
Дата | |
Msg-id | 20000417182027.B15776@garman.uwillsee.com обсуждение исходный текст |
Ответ на | Re: To BLOB Or Not To BLOB (Stephen Davies <scldad@sdc.com.au>) |
Список | pgsql-general |
On Mon, Apr 17, 2000 at 06:12:37PM +0930, Stephen Davies wrote: > 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) The problem is solving why stuff breaks if they are left on the filesystem. Here are a couple of suggestions for what in my opinion should be done when leaving data like this on the filesystem. 1. have a separate mirrored filesystem for your file data so that this kind of data is not competing with other data/logs etc. It also makes it more obvious that this data is important. 2. Have a cleanup policy if the filesystem grows alot, or introduc monitor levels where you assign new disk. 3. scatter the file system with a README file saying why the files are important and what is using them and what cleanup policy is in place. Also tell them who to ask questions to, like an email list etc. 4. Use relative path names rather than full to reference the data this way if stuff has to move it is easier to update. The problem with program data, is that sometimes it is hard to tell what is important and what isn't if you are not close to the application or as the application gets older, so stuff gets moved and things break. > A database that can hold the BLOBS internally avoids this sort of snafu. I think that depending on what you need, it is very valid to implement both ways. Cheers, Tom.
В списке pgsql-general по дате отправления: