Sharepoint for transactional systems

Question

I have done some research and it really seems that implementing a transaction system based on Sharepoint lists .. is a wrong design decision.

However, I am still of the opinion that you can somehow leverage sharepoint benefits, even for transaction systems. I was thinking of 2 options: 1. Use a separate database and use BCS to connect with the data 2. Just use sharepoint for hosting web parts, all data access and data presentation should be implemented from scratch.

I am a bit curios if there is a good case study of other systems. For example, I know that Infor is now using Sharpoint. But from what I can understand they just use the concept of webparts (as point 2 above). All data would be stored in the Sun database. and even the screens seem to be custom built. And I don't know if they use BCS in any way. However, they have used Sharepoint webparts very well to build a dashboard like experience.

Any assistance would be greately appreciated. I would need example of case studies to support my argument that sharepoint is viable for transactions systems. And perhaps any ideas/tips/pitfalls when implementing a transaction system on sharepoint.

Edit - these are some pain points that I have found in Sharepoint when used for Transactional systems.

1. You cannot use transactions. If you update multiple lists - you cannot do this in one atomic transaction.
2. The abstraction layer between Sharepoint and SQL means that you lose several benefits that SQL has to offer. You cannot create stored procedures because you should work with list. You cannot work directly at the database level because you should pass through Sharepoint. Some optimizations cannot be applied.
3. Joins have some limitations in Sharepoint. This greatly limits your analytical possibilities.
4. Sharepoint stores your data in one table which causes a number of issues. You cannot optimize that much.

I can't answer your question from experience, but I would enjoy earing more about the research you have done that suggests SharePoint lists shouldn't be used for transactional systems. — Jim Parker
Jim - Thanks for your reply. For example, sharepoint lists do not support transactions, they tend to slow down with very large lists, you lose database features (for example you have to query through CAML where certain elements like joins are very limited). Basically sharepoint lists are simply not a database — Joseph Caruana

lem.mallari lem.mallari · Accepted Answer · 2012-06-24T14:41:29

It really depends on what specific application you're planning to create. You can still use SharePoint as a front-end for any web based applications and just create custom web-parts like you mentioned.

You can use lists as tables to an extent. From SharePoint 2007, Microsoft mentioned some limits for 2010 and 2007 per list before performance issue is noticed.

Other things I can think of is being able to use SharePoint workflows and e-mail notifications based on certain things done in your application. You can create a simple audit trail list as well and when an error is logged an e-mail will be sent to you or your team.

It really all boils down to what specific application requirements you need. You can update your post and I'll try to help you as much as I can. :)

Sharepoint for transactional systems

1 Answers