I was just curious to see if anyone stored their images directly in the database as opposed to storing a filename reference to a physical file.

If you are storing in the DB, why?

--Bob

I have only heard of one situation where the entire image was stored in a database and it was a VERY specific application. I don't remember the exact details, but the developer I was speaking with was working on an application for a Police Department, and part of their internal security was setup so that the SQL server was actually secured - so they simply used it's security an put mug shots in the database itself instead of on another server entirely.

I do not currently store images in a database, however for an upcoming project I will be storing images in a database.

The upcoming project will essentially be a listing, where each item in the list (which will be frequently updated) will have an associated set of pictures (above and beyond the constant site logo). Because all of the other data about each list item is in the database, and because the list will be dynamic, it makes sense to put it all in the database.

I also hope to "skin" my website, and allow users (or maybe resellers) to build/choose their own skin. I plan to store the configuration details, and all pictures in the DB since it seems to be an easier, more efficient, and more secure way to manage the skins.

My criteria for storing pics in a DB or not, is whether or not the set of pitctures needs to be dynamically switched and expandable or not.

I can see how there would be a security benefit since images would be better contained than in a file system.

I don't think there is really any performance gain or loss either way.

I think there would be a certain performance loss on large scale systems because there's a lot more data being piped in from the SQL Server (which is on a separate machine).

Also, I'm not sure how database transactions would fare when dealing with that much data in each record? If the images are of decent size that may not be much for a web browser, but SQL takes up a lot of RAM just dealing with 1k and 2k records - I wonder how it would handle 50k - 100k records?

Well, that guy Paul in England does that for his sites, and except for the oddball problem (which was quite hard to figure out) it seems to run good, just a tad slow.

He runs the site w/ the models...

Uhm...could you be a bit more specific?

I'm trying lol... Kevin and Ben know who he is... he calls at like 2AM every night and wants to tell stories about being intoxicated and about his girlfriend in Washington State, and backup his DB's, etc etc... *bangs head* why can't I remember his name!!! grrrr... I used to love the phonecalls from him... they're the absolute best... and a great way to pass 2 hours.

impetusweb.net, impetusnet, something like that...

Been hittin the crack pipe a lil hard lately eh Josh?

I store PDFs within an SQL database for one of my clients.
The key benefit is security.

The PDF images are scans and "printouts" for which access is strictly controlled by federal law.
IIS (and users of the website) only has privileges to run specific stored procedures which filter data based on login credentials. This ensures that it is only possible to see image "files" based on account permissions, even if you save the URL.

The data size is a significant issue to contend with.
Images are being generated at a rate of about 100Gig per year, where traditional database data is less than 5% of that.
Day-to-day server performance (dual 3Ghz SQL server) is not an issue, but backup/restore times are a concern.
The traditional data is stored in a seperate database on a daily backup cycle.
In the event of a major server failure, this could be restored from backup within an hour or two and the client could be operational without online images.
Images are stored on a seperate RAID array and are on a weekly backup cycle.

Hope this helps.
Have fun.

I was the one who wrote an application to store the actual images in SQL Server using the Image type field. I wrote the app in .NET. It was kind of a pain.........We have the servers locked down so much, you had to give permissions to every little thing. We had to create a temporary file .JPG file when we retrieved the image and the .NET application would create some random name for the image.

I'm sure it's effected performance, especially when it comes to storage space. However, we have limitless storage, so that's not a concern unless you are on a shared SQL Server plan like HMS offers. Although.....I'm sure that effects our performance/speed as well to an extent.

The only other drawback was when it created a temporary .JPG file, it stored that file in a directory that I setup. So, if your not careful and don't delete the temporary files every now and then, you could have a ridiculous amount of temporary .JPG files in that folder.

It was a pain. Again, we only went this route for the extra security. I would just store the path in the db for just about any other application.

MB

There's an article in the Dec '04 issue of "asp.NET Pro" magazine about how you can provide images to the user without using temp files. So, if you're using ASP.NET, you can stream images directly from a database on demand to a browser from an .aspx page.

^^^ That's what I was just going to suggest... all you have to do is read in the stream and output the jpg... I use it for dynamic image resizing all the time... check this out.

http://joshwithrow.com/gallery.zip

Thumbgen.aspx is what you're looking for. That should at least send you in the right direction. Instead of reading from a local file though, you can read from you DB output. That would save you LOADS of space

Anyone tried pulling images from a DB using ColdFusion?