>>>>>Store paths to the images. Keep your database from massively bloating.
>>>>>
>>>>>Been there. Done that.
>>>>
>>>>Do you mean that with varbinary(max) the database is bloating? We're using it here and several of images with ntext / text fields as I found yesterday...
>>>
>>>Unless you are only going to store a few images, you can count on the database growing dramatically simply because the binary data is so much larger than any normal text records you are storing. Also, because each image adds a noticable increase in size, you will find the database has to physically grow more often, which can be painfully slow when it happens.
>>
>>Did you also implement physical paths for WEB app? It's probably a bit late for us to change the structure now...
>
>I haven't had to store images for a web app - only windows based apps. That still is probably do-able, but it does add complications depending on where you can store files.
>
>Storing images in the database makes coding much easier, but be warned that your database will suffer performance-wise if nothing else (assuming you store a lot of and/or large images).

PMFJI,

I've had (modest) success using the following approach(es):
- Keep the images in a separate database, and on a dedicated physical *drive* if possible; relate those images to the rows in your main database using GUIDs; if you must store them in the main database, ALWAYS store images in their own child table -- NEVER with any other meaningful data;
- Build your sprocs and queries ONLY in the main database, preferably against views which use fully qualified pathnames to get to the image ONLY when necessary;
- Before creating the database, defrag the physical drive where the database will reside;
- When initially creating the database, specify a large initial size and a large growth rate: this will not only assist in keeping as many disk sectors contiguous as possible, it will lessen the number of situations (and the speed penalty) when the database must grow;
- Regularly truncate your log file(s);
- Make *certain* that the drive where the tempdb database exists has LOTS of available space; otherwise, any queries that reference the images database/tables and return even a medium-sized rowset will fail abysmally (usually after about an hour of waiting when the report is due in an hour and ten minutes).

HTH.