I can think of a few good reasons to store images in the database, but I also have one very good reason not to.  My web hosting service gives me 200MB of disk space, but only 50MB of SQL Server database space, and I'd rather not have to pay for a huge service upgrade just to store images in my DB.  I have considered a few workaround solutions, such as rewriting the middle-teir component to write DB images to the file system, or perhaps changing the Stored Procedures that retrieve and save an image, but haven't tried implementing anything yet. 

I'm actually still in the evaluation phase of this starter kit, and I'm considering DotNetNuke as well.  DotNetNuke has some distinct advantages over the Starter Kits, including that is stores image files in the file system.    I'm leaning in the direction of the starter kits right now because it seems to do a little more "out of the box" (i.e. Photo Galleries) and has a learning curve that is not as steep as DotNetNuke, but I do have to get this image thing resolved. 

Has anyone built a workaround for this?  Any insights from your comparison of these two systems?

Thanks,

Jon

The CSK does store some images in the file system in some area i.e \Communities\Common\Images
If you require the ability for users to upload images to the filesystem this would be more complicated as most of the CSK directories do not physically exist on the web server. You would also need to consider webserver directory permissions to permit upload, file naming conflicts and the ability to restrict access based upon user roles.

I did a brief feature comparison of CSK and DNN some time ago.
http://colin-munford.me.uk/community/Programming/CSK+FAQ/390.aspx

I was not implying that users upload directly to the file system, I was thinking of something more like inserting some code into the stream just before the ImageSave() stored procedure, so the logic and flow of the app is essentially the same.  Something like this:

<pseudocode>

public void SaveImage (OtherParms, img)

   {

   if (img.Size < 1000)

      imgID = sp_SaveImage(OtherParms, NULL);

      SaveToFileSystem(img, imgID)

   else

      sp_SaveImage(OtherParms, img);

   }

public img LoadImage (imgID)

   {

   img = sp_LoadImage(imgID);

   if (img = NULL)

      img = LoadFromFileSytem(imgID);

   }

</pseudocode>

I'm not sure how this will perform, probably not very good, but CPU time is cheap these days...  I'm not a web guru, so I'm not 100% certain this approach would even work.  Any thoughts?

By the way, as soon as I posted my previous message, I realized how silly it was to think I could do such a thing in the SP.  The DB server is certainly not even the same machine as the web server, and the DBA probably wouldn't like us using his file system to persist our images, even if it was possible. 

Jon

Colin was highlighting the security issues with saving images to the file system. Even if you don't allow the users to directly access the file system, in order to uplaod via the web site you still have to give the ASP.NET account write permissions to the physical folders where the images will be stored. This can be a real pain, especially in hosted environments and using the SQL server to store images is an advantage there.

But yes, assuming you have everything else setup right you could alter the image uploading to save to the filesystem instead of the database.  

I agree SQL Server space/cost is an issue but so is having to save files on a load balanced web farm. Writing to a database in my case is the best solution.

While I can concede that the cost of SQL server space can be a problem at some ISPs who for some reason think that SQL server database space should somehow cost more than regular hard drive space; these ISPs are also idiots or are just ripping their customers off because they get away with it.

The space is still hard drive space no matter if SQL server uses it or if IIS uses it.  

Further, these ISPs have competitors with more fair cost/MB structures that don't penalize for SQL server storage space, so if you are in serious need of more space, and your ISP gouges you for SQL storage, then just switch ISPs. Eventually they'll get the hint and put in more reasonable storage prices or they will go out of business.  

Hi all,

I have the same problem. I have finished code from a prototype I designed to store attachments (be they images, mp3, docs, xls, etc. etc.) in sql server.

I am planning  a subscription site and members would need to associate attachments with records in a table. I.e.- My Records has a 1->Many relationship with MyAttachments.

I am now architecting the full blown commercial version and I'm very concerned about:

A- Performance (Store in DB versus File System)

B-Obviously Cost as I need to pass storage costs on to my customers and I don't want to charge them a fortune. As time passes their storage costs will invariably increase unless hard drive storage gets exponentially cheaper in the next few months :D <ya never know but i wanna deal with the "here & now">

C-Security: Not even sure of the considerations here

 Note: as a point of interest I use filesanywhere.com and they only charge 11 dollars per month for 5 gb of storage but I have not seen any host anywhere come close to this price for db storage.

I simply have to have low cost attachment storage and high performance and I need to be able to scale to the Nth power. This is mandated by my business plan and subscription model.

All my sites I have created thus far have been corporate intranets so if anybody really has concrete answers I'd be grateful.

Thanks!!!!! 

 

 

 

The images in question are those in the photo gallery or the books? They are stored in the database? Where? Table Community_ContentPages? In that field?

 There is no reason to store image in a database other than that of conveniance. Storing images in a directory requires close attention to permissions.

I know this is a late reply, but disk space for a database in a typical design would cost more than file storage. In a large environment as, an ISP would have, you would want to have your databases and high I/O systems on your fastest disks and then use slower disk for you file storage. Taking this premise to database design in MSSQL 2005 and beyond you can setup file groups within your database and may choose to place your tables that store pictures and documents in a file group that is stored on cheaper slower disk. Another advantage of dividing your database into file group is that it allows you to have a different backup strategies for the different file groups. Presumably if you are storing images and documents they probably do not get as frequent changes. These files would be uploaded and left there especially if your are storing them for archival purposes. Because of this, you may choose to reduce your backup frequency. In my opinion, in today's databases with today's hardware it is better to store images and documents in the database not to mention the added security and because the images/files are in the database there is no chance of having an orphaned record or orphaned file/image.