I started my career in the scanning, document analysis and archiving industry. One question that always comes up in this industry is the following;
Is SharePoint suitable to store images, and when yes, how should this be done?
As usually there is not a simple definitive answer to this question, but in this post I will try to explain when and how you can use SharePoint as an image repository.
Some of the benefits of storing images in SharePoint are metadata storage, custom views, check-in/check-out, version history, basic workflow, and in the case of SharePoint Portal Server, full text indexing from OCR information. But SharePoint is designed to be a collaboration platform and is not designed to be a replacement for local file servers as a pure storage platform.
In general terms, SharePoint is an excellent image repository where users can store their images, whether for personal or shared use. There are, however, specific scenarios in which SharePoint is not the optimal storage location. This is depending on a number of variables that I will describe in detail below.
Size of the imagesYou can store any type of files on SharePoint as long as the files are each smaller than 2GB, and are by default around 60MB (this can be configured to be changed up to 2GB). But the 2 GB maximal file size is really a hard limit that cannot be changed. So when you have image files that are bigger, you cannot use SharePoint as a storage location.
Of course it is possible to store the actual file on a fast network device and only keep the path in a SharePoint Document Library (or create a simple list item and store the link). You need to make sure that only the process account has direct access to the network device and you may also need to write custom code to prevent unauthorized access.
This way you can take advantage of the SharePoint UI, Security, Target Audience and Search feature and also optimize the user experience and performance. But this solution requires careful planning, coding and security testing.
Number of imagesBefore you decide to store all your images you have to make a simple calculation: average image size * number of expected images to store = expected database size. According to the official documentation on
TechNet the expected database size should not exceed 100 GB;
In most circumstances, to enhance the performance of Office SharePoint Server 2007, we discourage the use of content databases larger than 100 GB.
• If your design requires a database larger than 100 GB, follow the guidance below:
- Use a single site collection for the data.
- Use a differential backup solution, such as SQL Server 2005 or Microsoft System Center Data Protection Manager, rather than the built-in backup and recovery tools.
- Test the server running SQL Server 2005 and the I/O subsystem before moving to a solution that depends on a 100 GB content database.
• Whenever possible, we strongly advise that you split content from a site collection that is approaching 100 GB into a new site collection in a separate content database to avoid performance or manageability issues.
• Limit content databases that contain multiple site collections to approximately 100 GB.
But this is only a recommendation. There are numerous examples of SharePoint using databases bigger than a terabyte. There is no size limit per se in SharePoint. Your size limitations are defined by what version of SQL Server you are using.
However, your backup and restore times will increase more than linear with your database size, and could cause degradation in performance as the database is backed up unless you have a SAN infrastructure that offloads this process. The issue with splitting the content database into smaller sizes is that this may change your navigation due to storing the content in separate site collections.
Invalid Characters and Long File NamesSharePoint has some limitations in the characters that can be used. The following characters cannot be used in the naming of files to be uploaded to SharePoint:
" # % & * : < > ? \ { | } ~ .
Additionally SharePoint file names cannot exceed 128 characters in length. So you have to make sure your image file name will follow these two restrictions.
Method of adding images to SharePointWhen you add your images programmatically to SharePoint you are good to go. But when users upload large files by browser you have to consider the following.
- Your browser could timeout while uploading a large file
- Your browser could run out of memory due to spooling
- If your upload fails for any reason, your upload will not resume itself. You will need to start all over again.
See also the article
MOSS 2007 - Uploading and Indexing Large Files from Suleman Ibrahim.
Access FrequencyIf lots of users are uploading/downloading large files at the same time, it could impact the overall performance of your SharePoint server. So you might want to think about setting up a dedicated Front End Web Server to serve the image repository.
Need for backups All SharePoint content has to go in the SQL database. That's just how it is. Having images in the SQL database can be an advantage or a disadvantage when it comes to backups. At one hand, all image data will be contained in a database backup, instead of having to sync database backups with file system backups. On the other hand your backup file size may grow to very large proportions.
SharePoint Picture LibraryWhen you made it this far, and all the variables mentioned above make you think that for your use case SharePoint is suitable to serve as image repository I have good news. SharePoint has a picture library list type for doing exactly what you're trying to do. Microsoft wrote a very nice
article about working with the SharePoint picture library.
Although you can also store images in other types of SharePoint lists and libraries, there are many advantages to using picture libraries. These advantages include viewing images with one of three unique display styles, sharing images by using slide shows or by sending images directly to Microsoft Office programs, downloading images directly to a computer, and editing images with SharePoint Services-compatible image editors.
Gavin Clabaugh went one step further, and wrote a very interesting
post about how he build a simple Digital Asset Management system on top of SharePoint.
Related Posts
Continue Reading...
Visifire is your best bet to create some astonishing graphs in SharePoint. Have a look at two of my previous posts on how to do this.
