Point – CounterPoint : What is the difference between a file server and SharePoint?
A while back, I published an entry level article: What is the difference between a file server and SharePoint? This still comes up frequently in workshop where people are trying to wrap their head around why the company has chosen to move to SharePoint.
This morning, Duncan Drury responded to that article with a good comparison of the two, including the times when SharePoint might not be appropriate.
Guest Response by Duncan Drury, dunxd.com
Having about 1TB of data in Sharepoint, I regularly curse a number of issues with Sharepoint:
1. Restoring files from a monolithic database is painful. Gigabytes of restore in order to get back a 100kb file? Not good. The other option Sharepoint makes available involves crawling the whole site to do item by item backups. Again quite painful compared to backing up/restoring from a file system.
2. Performance is noticably slower than a file system – people access documents via internet explorer. On the LAN they wait while Internet Explorer and the Office DLLs communicate, before the file opens in the appropriate application. It was instant from the file system.
3. We keep hitting up against this issue where an install of Office 2003 will only allow opening documents in Read Only format, no matter how you open it. Even reinstalling Office doesn’t fix it – the only fix we have so far is to rebuild the PC from scratch.
4. When opening a http:// link to a sharepoint document in an email for example, it opens in Read Only mode.
Sure Sharepoint is great for Workflows and metadata and other document management processes. However, unless you know what and why you want to do these things, a file system is a far easier place to maintain documents. The model I am starting to feel my way to is to allow users to work on documents in a file system. Once they are complete, upload them to sharepoint.
Sharepoint can index documents in file systems. So far this is about the only benefit we have had from Sharepoint for 95% of the documents stored in it. And the docs don’t need to be stored in Sharepoint to benefit from that.
on
Good points, Duncan. I’m sure many people are in a similar scenario, and moving thousands of files into SharePoint really isn’t a good solution. So many organizations have file servers loaded with arcane folder structures and rarely used documents. I think the only sensible approach is to have SP index your file server, and mandate that “new” documents that meet certain criteria should be put in SP. Have users create/work on documents on the file server,but when it is time to collaborate/publish/share the document, then move it into SP.
But why even put them in SP if you can crawl the fileshare anyway? I just had a thought that could help out SP. Do not let users store documents in SP! Enable them to work and write documents in a wiki format, then when the time has come to make it final, allow an export to .doc or whatever filetype that makes sense. That way it would almost be impossible for SP to become a glorified fileshare. Not to mention it would allow people to grasp the power of SP a bit easier.
Matt- crawling the fileshare helps you find the files, which is a good value add. But putting files in a document library gives you versioning, expiration, reviews and workflows, and metadata. Much easier to organize and enhance findability.
One of the real problems of keeping things on fileshares is that findability is essentially location based- you need to know where the document lives, or if it is indexed by SP, what it is called or what the content is. Not so if it is in a document library- use views to leverage the metadata and expose documents in many different ways, plus have documents appear in multiple “folders” (actually views) without creating copies.
A real paradigm shift, but worth doing. Wikis are too unstructured, and I doubt any users would like getting used to accessing the content in a wiki and then seeing it in a different context in a document format.
I just spent the last five minutes building a wiki. I was able to set required column(metadata) on the wiki pages library, easily looked at new and old versions(OOTB by the way w/ a wiki), created a folder for a locked down wiki(ease of use on permissions) and was able to easily create the views you described with a simple DVWP and some clever filtering on my metadata. Wiki’s wouldn’t be too far fetched to use in my opinion b/c they are prepared to handle content OOTB. The truth is that a wiki is unstructured in nature but that can all be handled exactly with what you described b/c all of the pages are stored in a Doc Library. What would be nice is if I could create a content type for my wiki that would know what the end game is… Word Doc or Excel and template my wiki accordingly and add a nice *Export To and Send To* feature when the document is finalized. That brings me to another point, Workflows can also be enabled on a wiki and findability isn’t a factor now that the wiki is stored in SP. End game would be to revamp wiki’s to not even necessarily use them as a traditional wiki, but more of a CMS. There are some wicked workflows you can create with a wiki b/c all of the content is accessible via workflow. It’s more of a wish list suggestion but it seems as if it should’ve already been done…
Concur with Greg for the reasons he stated. Particularly and especially current and currently worked on files. Move that content from file servers and into SharePoint, leaving behind what is no longer used and can be archived. And also archive content off of SharePoint to the file servers as necessary.
But having seem SP2010’s ECM and related features and Windows Server 2008 R2’s File Classification Infrastructure (FCI) feature demoed at the SPC09 conference, I’m thinking we’re all going to rethink SharePoint and File Servers when (whenever that is for each of us) we move to these new versions. I think the two together and their integration change the game. For the better.
Duncan, the Recycle Bin will give user’s 30 days grace to restore deleted items, and there’s 3rd party solutions for SharePoint — whteher for SP only or as part of an enterprise product as an agent option — that do item-level backup and restore.