Sharepoint as a replacement for N-Tiers Applications and OLTP Databases

Question

All,

At my current company, we are looking to replace all ASP.NET Applications and OLTP databases with Sharepoint 2007. Our applications and databases deal with 10,000+ rows, and we have 5,000 + clients actively using the system. Our Implementation of sharepoint would replace all n-tier applications.

Does anyone have an experience in implementing this? My current viewpoint is that Sharepoint is not built for or adequate enough to handle this type of application. Can it really replace application with hundreds of pages, and hundreds of tables? Support Data warehousing operations? Support high performance OLTP operations? Provide a robust development environment?

Any and all input is greatly appreciated. Thanks S.O. Community.

Answer 1

http://stackoverflow.com/questions/256407/what-are-your-biggest-complaints-about-sharepoint

http://stackoverflow.com/questions/832465/how-good-bad-is-sharepoint-programming

Basically not a good idea to shift to sharepoint. Difficult to use. Steep learning curve. You would probably need sharepoint consultants.

update: http://stackoverflow.com/questions/1848462/developing-a-website-for-3-mln-users-sharepoint-or-pure-asp-net

http://stackoverflow.com/questions/1293912/sharepoint-cms-vs-umbracocms

might be more relevant to you.

Also you may want to look at http://stackoverflow.com/questions/120949/running-away-from-sharepoint (just kidding)

Answer 2

The view on Sharepoint at my company, is that the features it brings to table (versioning, views, and caculated fields) can not be coded by .NET Programmers, and these features are only in Sharepoint. Further more, it is also the view at my company, that by using lists Business Users and Project Managers can alter and control the Schema of Data.

WE currently have many performance issues with the small implementation of Sharepoint as an OLTP. The Application's one list, contains 600 Rows and 350+ columns. Since Lists can not be related like tables in a database, lists are designed flat and large. Our project managers and leadership "are drinking the kool-aid" when it comes to sharepoint.

Answer 3

SharePoint is a platform, like any other, it has strengths and weaknesses and can be made, through various levels of effort, to do anything you really want to with it.

Can SharePoint handle the load you ask about? Without a doubt. Can it support your data back end? Sure, either via the "SharePointy" mechanisms of the BDC/BCS, or though your own custom code.

The better question is what is to be gained from essentially re-developing all of your applications on a new platform, if anything?

Don't be swayed jump on the SharePoint ship because Microsoft is selling it as the new shiny. A thorough knowledge of ASP.Net is required for development in SharePoint, but having that alone doesn't allow for a rapid start-up in development.

Answer 4

SharePoint can absolutely handle this this level of data and users. But I'd have serious concerns though about whether the people in the organization can adequately manage, develop, and use such an implementation. There are hundreds of wrong ways to do things in SharePoint, and very few "right" ways.

At the level of usage you're talking about, you're going to have to do some serious customization and development. You'll have to be careful that people don't get fooled into thinking it will work for them out-of-the-box.

Answer 5

Here's some info on Sharepoint capacity planning: http://www.microsoft.com/resources/documentation/wss/2/all/adminguide/en-us/stsb07.mspx?mfr=true

It suggests that more than 2000 items per list is a bad idea. I've heard the same guidance in the past.

This sounds like a good way to shoot your company in the foot and move on to a lucrative sharepoint consulting career. I recommend wearing steel-toe boots and working on that exit plan early.

Answer 6

Thanks all for your answers!

After reading all of the feed back, it seems to fall in line with my research. Having said, here is what I gather from your responses:

• SharePoint out of the box is a CMS.
• SharePoint Lists do not replace relational tables.
• Extending SharePoint to fill other uses is limited to custom development within the SharePoint framework.

From my research: - Utilizing a relational database in a SharePoint application is done through custom code. Adhereing to point 3 above.
- Developing and building applications in SharePoint, with features that fall outside of the CMS domain , nullifies many sharePoint features and requires heavy custom development.

Again, thank you all for your feed back, this ihas invaluble to my research.

Answer 7

For posterity , and anyone else who stumbles here.

Further points: - Most Developers do not have enough SharePoint Development Knowledge to properly implement a solution with SharePoint. - ASP.NET Knowledge is required to develop SharePoint applications. - SharePoint Maintains a step learning curve.

• Are we saying that developing on a platform built on top of ASP.NET is harder to learn then ASP.NET it self?

Answer 8

Ouch man, I don't know if you want to head down this path; SharePoint has a pretty notorious learning curve, isn't something easy to bend and flex too much.