SharePoint with Attitude…

Does SharePoint suck? No way!!, but with a client today, I got that comment from one of their developers.

I’ve heard that comment too many times, and every time I hear it I laugh way too much; mainly because it reminds me when I hated SharePoint too, yes I also thought that SharePoint sucked, but that was when I first started to work with it, long long time ago…

If you think about it, every time more and more companies are implementing SharePoint, why? because the business people see a value in it, they see what SharePoint can do to improve their businesses and operations.

Having more SharePoint implementations, requires more people working in SharePoint projects, and let’s be honest not too many people are really “SharePoint developers or experts”, most of the people working in SharePoint are .NET developers.

Which brings me to the question: who is usually the people complaining about SharePoint and saying that SharePoint sucks? the answer: the developers.

Interesting, why does this happen?, well it’s easy. SharePoint is based in .NET, and for many people is easy to think that if you know .NET then SharePoint will be easy for you.

The thing is, if you know SharePoint, then you know .NET; but if you know .NET it does not mean that you know SharePoint, yes it is an advantage, because it means you know the basics, but there is still a learning curve.

Usually developers are thrown into SharePoint projects just because they know .NET, without a previous training/knowledge of SharePoint. It means they will learn SharePoint on the road, and that learning curve can be painful (ask me! lol). It is usually because of the lack of knowledge in SharePoint that people say SharePoint sucks, because we wan to do things the way we are used to in .NET, and things that can be done in 5 min in .NET, take hours in SharePoint, so we get frustrated.Let’s not forget that SharePoint is a platform, it has its own way to work.

Now I’m not saying that doing a project in SharePoint is better than doing it in ASP.NET for example, or than doing it in ASP.NET is better than doing it in SharePoint, It just depends on the project, there will be projects where it is better to do it in SharePoint and other where it is not, SharePoint Architects play a key roll in here.

This, also brings a person to say that SharePoint sucks, when the sales people sale a project in SharePoint (because they just want to sale) without analyzing if it is convenient or not to do it in SharePoint, it will become frustrating for the developers to meet some requirements.  At the end the developers will be the ones working on the project that was not suitable for SharePoint and they will end hating SharePoint.

In conclusion, SharePoint is a very robust platform, and you have to know its architecture and go through that learning curve in order for you to be able to work in a SharePoint project and not get frustrated in the way.

After a couple of projects working with SharePoint, you’ll understand more and more about it, and I’m sure you’ll like it, and probably you’ll even love it! just like I love SharePoint.

Love not hate people!

  A SharePoint Services implementation has: 

• One Configuration Database
• One or more Content Database

 SharePoint Portal uses the following databases: 

• Search Database
• Shared Services Databases
• Shares Services Search Database
• SSO Database

 In this post I’m going to focus in the configuration database and the content database. If you are interested in more detail about the other ones, click here.

  The configuration Database 

The information on this database can only be updated through the Administration site. It stores the following data: 

• Global Configuration: Information regarding the farm servers, for example which are the web servers or the database servers in the farm.
• Virtual Server: Information regarding each virtual server in the implementation, for example, which SMTP server is being used.
• Site Map: Information regarding the relationship between web applications and their respective content databases. When Windows SharePoint Services receives the URL of an application, the settings that determine which database is the database that contains the data content of the site.

 

Example: When a request is send to the server to http://MyServer/sites/mysite/Lists/AllItems.ASPX The relevant part of the URL, sites/mysite specifies the site collection of the application. Since, by default, sites offering wildcard inclusion of site collections created on the server, sites/mysite is a piece on the virtual server that specifies the site collection. Because the relevant part of the URL to exclude the name of the team, two virtual servers with the same or different addresses can serve the same content, site data may, for example, a site geared toward both the extranet and to the intranet site.

In the example above, the configuration database specifies that data for the site reside within a database server called ITG_STS_1 in database called STS_01. After collecting this information from the configuration database, the ID of the database (101 in Figure 6) is cached in the session cookie and Web server used to connect to the correct database in the following applications. Windows SharePoint Services uses optimistic caching scheme, ie, which implies that the site has not moved since the last visit by the user. If the URL is not cached, Windows SharePoint Services queries the configuration database to check whether it has moved the site and an automatic correction algorithm allows adjustment of the system.

The Content Database. 

SharePoint uses a  fixed database schema and a fixed number of databases per server to improve scalability.

The Sites table contains the configuration for each site collection represented in the database, it is a default setting that applies to all subsites created within each site collection. The table represents each of the top-level sites for each of the collections of sites as well as the root site and my site in the context of a portal site.

The Webs table contains the settings that apply to each of the sites within a site collection.

The Docs table. stores all documents of all sites in a site collection represented by the database, including, for example, documents in document libraries, attachments, and nodes for each list, and also pages and user default.aspx for all the lists if they are personalized. The contents of the table column DocFlags. contains the value NULL if no pages have been customized. When creating a site for the first time, the column contains the value NULL content for all pages of the site that are in the table because they are not customized,  the page definitions are extracted from schema files physically located on the Web server.

The table Alllists contains one row for each list of all sites in the database. This table contains the settings for each list, which specifies the lists and document libraries that are included in the sites and what scheme is instantiated with each list.

AllUserdata table contains all the list data to elements in user-created sites, each row contains data for each element.

The AllLinks table contains the links used in the repair of links to recalculate.

The WebParts table contains information about all web parts and views in existing Web sites.

 The personalization table stores information about Web Parts customization.

Conclusion: Everything (or almost everything) in SharePoint is stored in the databases, so having a Database back up can save you in a disaster case (One day I’ll tell you about my first disaster with SharePoint… DB saved my life)

Updates to the data done directly from the database is not supported by Microsoft.

People working with SharePoint come from a .NET background, and for most of them when first introduced to SharePoint, they have no idea of the monster they are about to confront.

Specially because they are put in SharePoint projects without a previous training, the result: they end hating SharePoint, and I don’t blame them (I hated SharePoint for a long time, but it’s a fine line between love and hate ).

So here comes a little explanation of the SharePoint Architecture and how it integrates with IIS and ASP.NET.

SharePoint Services are the heart of any SharePoint implementation. It has 3 components: 

• One and ONLY one configuration Database.
• One or more Content Databases
• One or more Web Servers. 

The configuration Database is the heart of any SharePoint farm, it contains the majority of the farm configuration, including web applications configuration, logging and reporting, farm topology, services on servers, antivirus, content databases, authentication and much more.

 The content database stores all the content of the site, including documents in libraries, data in lists, user names and privileges, etc. 

There is one content database per Web Application. The web server will be responsible to receive the user requests, the web server will connect to a database in order to get the data that will be returned and displayed in the client page.

 

SharePoint Integrates with Internet Information Services (IIS) and ASP.NET. It is designed and implemented on top of IIS and extends the ASP.NET framework:

  When SharePoint is implemented, two virtual servers are created in the IIS. On of them is for SharePoint Administration and the other one for the final user.

For every new Windows SharePoint Services Web application created, one new virtual server will be created in the IIS, it also involves some changes to the file system and the IIS metabase on each front-end Web server. In a Web farm environment, these changes are automatically mirrored across each front-end Web server in the farm by the Windows SharePoint Services runtime.

Once a Web application is created, it is no longer necessary to touch the file system or IIS metabase of the front-end Web server when creating, updating, and deleting sites or site collections. The Windows SharePoint Services architecture makes it possible to provision new sites and site collections simply by adding entries to the configuration database and a content database. It is this aspect of the Windows SharePoint Services architecture that gives it significant management and provisioning advantages over ASP.NET.

For an extended explanation of IIS and ASP.NET concepts related with SharePoint click here:

For an extended explanation of the SharePoint Databases click here.

Conclusion:  SharePoint Services expands and diversifies itself as a Web development platform through integration with. NET Framework on its own functionality. Understanding this architecture will help you determine how to develop applications on the SharePoint.

This is a good info that everybody working with SharePoint should keep in mind:

The following values are recommended for an acceptable performance with SharePoint: 

• Web Applications: 99 per SSP
• Site Collections: 50,000 per web application.
• Zones: 5 per farm.
• Content Databases: 100 per web application.
• Web Sites: 250,000 per site collection. The recommended is 125 sites with 2,000 subsites each.
• Sub Sites: 2,000 per web site.

 

• Documents: 5 million per document library, over 2,000 elements velocity is slower to present the data in the page.
• Document Size: The default value is 50MG, it can be changed to support until 2GB.
• Lists: 2,000 per web site.
• Metadata: 256 per list.
• WebParts: 50 per page.

 

• Users in groups: 2 million per web site (using AD)
• User Profiles: 5 million per farm.

 

• Index Documents: 50 million per index.
• SSP: 3 per farm.

 

• 8 web servers for each Database server.
• 3 web servers for each domain controller.
• One index server per SSP.
• Servers for excel services: no limit.
• Servers for Queries: no limit.

 

• Workflows at the same time: 15.