Uncustomized (Ghosted) Vs Customized (Unghosted) Files within SharePoint

I beleive that understanding the differences between Uncustomized and Customized files is the key to uncovering the power of the SharePoint platform.

It is what enables SharePoint to provide a rich configration interface for the "power user" but at the same time provide a mechanisim for a more traditional development approach.
It is also the most mysterious part of SharePoint to any new developer as this concept does not really exist in the standard .NET world.

Here is an attempt to explain the difference:

Both Uncustomized and Customized files live within the logical structure of your SharePoint site and hence in the Content Database(both types of files can be seen from within SharePoint designer). However the difference is that with a customized file the "complete file" exists within the content database whereas the uncustomized file the entry within the content database is really just a pointer to a "file" on the physical file system(under the /12 directory).

This "file" could also be thought of as a "template file" and you can have multiple Uncustomized files within your SharePoint site pointing at a single "template file".

This is the area where SharePoint comes to the party for developers and enables us to do things such as easily move content through environments(DEV-> UAT-> PROD as we can move physical files much more easily than the complex database entries of a customized file) and also make changes to SharePoint sites in a centralized place. Lets say you create a new uncustomized "template file" and users use this template to provision 100 pages. Now the business requirements change and we need an extra control on this page. If this were a customized page we would need to add the new control to all 100 pages that are stored within the database. This is a real nightmare. However with uncustomized pages all we need to do is add the control to the "template file" on the physical file system and we have 100 pages immediately satisfying the new business requirement.

The Customized file really tells the story for the "Power User" or "Information Worker". This is where the power of SharePoint Designer comes into play.
A customized file can be created in a couple of different ways.
Firstly you create a customized file by using SharePoint Desginer to modify a template file like the ones mentioned above. The changes you make are now stored in the database and SharePoint no longer looks at the file system based file.
Alternatively you can create new SharePoint content directly in SharePoint Designer, for example a new page layout. This new layout is stored directly in the database.

Obviously this is very powerful as we can now remove developers from the equation, and SharePoint gives the Information Worker the ability to rapidly and extensively change the makeup of the site.

Getting the balance right is one of the fundamentals to any good SharePoint project. Too much work with customized files excludes some the nice things such scalability inherent in the development approach, not enough work with customized files and we find that business owners are not getting all the promised benefits of the SharePoint platform.