Re: Storing images in SQL database?

"(Pete Cresswell)" <x_at_y.z> schrieb im Newsbeitrag news:33o3m0d55odt8l8b480t6kkbp6r5q85ogf_at_4ax.com...
> RE/
> >1) To store everything about the image within the SQL database, and
> >the image itself on a file system. A link to the image in the file
> >system is also stored within the SQL database.
> >
> >2) To store the everything, including the image within the database.
>
> When I had to do this, everything I read pointed to #2 as the
> "good-right-and-holy" path. I even read something to the effect that one should
> *never* use the file system to store data.....and it all made sense to me.
>
> However, when I tried it, (albeit with an MS JET back end, not a "real"
> database) performance and DB bloating became an insurmountable problem.
>
> Consequently, under deadline pressure, I reverted to #1.
>
> I experienced no problems with #1 - except for:
>
> a) The nagging knowledge that if the file system were to somehow drop a file,
> nobody would know until somebody tried to exercise it's pointer.
>
> b) That there seemed TB no way to validate the files short of an off-hours
> background job that exercised each pointer and reported on errors - in hopes of
> recovering missing files from backup.
>
> Those two considerations alone would make me think long and hard before doing it
> that way again.

I agree. Try to do a point in time recovery and you're shot with #1. Ditto for undo. ditto for standby databases.
I say do a prototype with #2 and see if the performance is *acceptable*. You don't need the fastest solution. However, what you do need is the vumanly best achievable solution in terms of design clarity, simplicity and consistency.

Greetings!
Volker Received on Tue Oct 05 2004 - 06:24:03 CDT