> Because you will lose the images when you do a restore from backup.
> And you will have to restore from backup eventually, count on it.
I think one should always plan for the worst case scenerio, that's exactly
thye you do backups, so you don't lose data.. Why would he lose data if he's
preforming backups and restored from that backup..
Unless the backup wasn't preformed or failed in some way, he wouldn't lose
any data..
> On the other hand, if your service will ever grow to more than one
> computer doing HTTP service (i.e. load balancing), you will have to
> have the items in the database or resort to unsightly things like NFS.
Again, I always think one should make an application scaleable but having
said that, I think what you're mentioning here is a cart before the horse
situation. Even saying he needed to load balance I'd never use NFS, ever.
Large RAID arrays and such could provide all the storage needed --
especially since we're just talking about images here.
> If you expect your site to get big or be busy, you will have to come up
> with a way (preferably an abstraction on top of pg_lo* functions) that
> will preserve the BLOBs in the database so that when you do a reload,
> you can pump in the BLOBs as well and connect their *new* OIDs with the
> appropriate table. Because the OIDs will change when you reload.
>
> You do have a backup plan, right?
I'd suggest that you don't use OIDs as binding record IDs, make another
integer field for that. There is an option to pg_dump to preserve OIDs even
if you do.
-Mitch