>Ok, why not?
>
>Several reasons:
>
>1) If you're storing a large # of images, it can be costly in some environments. SQL Server disk storage can be more expensive then normal storage on a web server.
>
>2) Depending on how you're using images in (for example) a web application, storing in a database can incur some performance overhead, as opposed to storing externally. Related, not all images are binary, so you need to go through what might be an unnecessary transformation. Additionally, if images are large enough, it might take SQL Server longer to reassemble them across database pages.
>
>3) I've worked for clients where there was a requirement to store images externally. I've never seen a client that stated a requirement for images to be stored in a database.
>
>4) Arguably provides more flexibility in working with images. I've worked with vendors who were involved with e-commerce solutions involving images, and felt strongly about keeping thumbnail/medium/large images outside the database.
>
>5) I'll admit I've never tried it myself, but I've read that table scans take a little longer when storing images (even using varbinary) as opposed to merely storing a pointer to a file in the file system
>
>If you're talking about a fairly small # of images, then you should probably go with the approach that you feel is the most efficient. However, if you're talking about a large # of images, the file system approach is better. FWIW, Photobucket uses an external file system - they make it known that they don't store images in a database.
>
>That enough?

If it was SQL2008 : Any views/experience on the comparative performance of FILESTREAM ?