C# SQL Database – How to Create a Minimal SQL Database in C#

Storing images in the database is not always a bad idea. If you have a small amount of images, say in the tens of thousands range, and they are small in size, sometimes the convenience of storing the images in the database outweighs the added complexity introduced by adding an additional storage server that needs to be written and supported into the mix. Is storing the image in the db the most efficient means? No. Does that matter if you only have 10 client applications accessing a couple hundred images a day? Probably not. In that case, live with the inefficiency and save yourself a lot of effort.

If you have a lot of images (millions, tens of millions,...I've worked on systems that track billions), then you'll want a seperate server application that can handle storage and retrieval of files. At the most basic level this can be (for example) simply a tcp/ip server app tha can handle requests for files, as well as accept them from across the network (a web server running a PHP script could be adapted for this). You'd just access the images based on an id in the database for a row that stores metadata about that image. Remember, if this is across a public wire, you'll need to implement your authorization system to access the images. More complicated servers might handle mirroring, file type conversions, and the migration of files to and from longer term (and cheaper) storage mediums.

Since you don't really need to run this "in" SQL Server and you don't need to reuse any of the code anywhere else in SQL Server, create another server application in the language of your choice and have it triggered by a scheduler. This could give you the option to off-load the number crunching on another server. Using stored procs are still an option if you need it.

You may not have CLR enabled, so why bother just for this?