views:

198

answers:

7

Hi

If Microsoft built MOSS so that all data is written to the SQL Server database, why do all best practices for development suggest to keep files etc outside of the database, i.e. on the filesystem?

All the best

A: 

This is a philosophical item. Transactional integrity is a benefit of storing the files in the DB. With that comes downsides such as ballooning transaction logs.

I would not be surprised if, in future versions of Sharepoint, MS gave you an option to store the files 'outside the database' by using the filestream feature of SQL 2008.

JohnW
A: 

Because of performance issues: save a round-trip to the database just to fetch your page layout, in the detriment of performance.

On the other hand, using files on the local file system for performance reduces customization options.

Tudor Olariu
A: 

Keeping the files in the database is necessary if you wish to have users of the website editing those files. SharePoint is designed for most of those files to be editable, so they are storable in the database.

If you as an application architect know that some high use files (page layouts, masterpages etc) are not going to be edited except by a solution release, you have the option to store the pages on the filesystem.

Storing on the files system has small improvement read in access performance as a database round trip is not required. The masterpage, for example is going to be needed for every page in the website, so having it stored on the file system is going to improve performance during high user demand.

The fact the SQL 2008 has the ability to manage files "outside" the database shows that this feature is not just desirable for SharePoint.

Nat
A: 

Keeping SharePoint pages uncustomized allows one instance of the page to be compiled on the first execution, then kept in memory and reused for all pages of the same kind. The reason why customized pages do not share this behavior is because they are unique, and once an ApplicationDomain loads a dll it can’t be unloaded. Therefore customized pages are parsed on every request.

JMD
+1  A: 

I would say that all best practices don't say that you should use the file system for storing files. It will always depend on the situation. Storing files on the file system is fine when you have a single server, but then you have to manage replication when the files need to be on more than one server. Backing up a database is typically easier than a database and files. All of these situations can be managed, but you need to be flexible.

BrianLy
I didn't hear of such "best practices"... 100% agree with you. I always try to put everything in the content database.
Romias
A: 

Where did you get those "best practices"?

In my experience with MS and MOSS I should say that never heard of such best practices and except for a very particular case... I'd say that this is not a good practice.

Your deploy is not easy this way... admin users have to know where to find which file to modify, backups are like hell, etc

But, as I say... may be in a particular case It could be useful.

Romias
I'm talking about development here, i.e. features, solutions, masterpages, layouts, webparts etc. Most technical books/articles by MVP's suggest keeping the files on the file system and not in the database.... I think! ;)
78lro
A: 

The SharePoint has a techniec called ghosing which is caching pagings in file system.

Khaled Musaied