| From: | Ragnar <gnari(at)hive(dot)is> |
|---|---|
| To: | Andrew Chernow <pg-job(at)esilo(dot)com> |
| Cc: | Jorge Godoy <jgodoy(at)gmail(dot)com>, John McCawley <nospam(at)hardgeus(dot)com>, Clodoaldo <clodoaldo(dot)pinto(dot)neto(at)gmail(dot)com>, imageguy <imageguy1206(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Database versus filesystem for storing images |
| Date: | 2007-01-05 23:24:24 |
| Message-ID: | 1168039464.6369.523.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On fös, 2007-01-05 at 15:49 -0500, Andrew Chernow wrote:
> I 100% agree. Use the database as a lookup into the filesystem. Don't load the
> database up with terabytes of non-searchable binary data? not sure how that
> would help you?
>
> >I mean, how do you handle integrity with data
> > outside the database?
> You don't, the file system handles integrity of the stored data. Although, one
> must careful to avoid db and fs orphans. Meaning, a record with no
> corresponding file or a file with no corresponging record. Always
> write()/insert an image file to the system within a transaction, including
> writing the image out to the fs. Make sure to unlink any paritally written
> image files.
what happens if you rollback a transaction that just updated
an image file?
for that matter, what happens if one transaction is using or
even reading an image while another is updating it?
gnari
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John McCawley | 2007-01-05 23:25:48 | Re: GUI tool that can reverse engineering schemas |
| Previous Message | Jeremy Haile | 2007-01-05 23:07:21 | Re: Database versus filesystem for storing images |