SharePoint Lists vs Database Tables performance

Question

1. We are looking to store transactional data in SharePoint lists. The lists will easily grow to 100,000+ items.
2. How would the query performance be compared with que

Answer 1

I also agree with the guys above However - a lot of the performance problems discussed in blogs are due to the fact that the SharePoint Object Model is not used correctly.

You can checkout my blog series about SharePoint List Performance at dynaTrace Blog. This series looks into the SharePoint Object Model to highlight what is actually going on between the SharePoint Servers and the Content Database

Answer 2

Don't do it. SharePoint is not good at handling transactional data and will perform badly.

Any abilities you might have to improve performance at the database level (like adding indexes) may have detrimental effects on the SharePoint installation (although columns in lists can be "indexed" through SharePoint.

Essentially SharePoint is designed for a specific purpose (content/documents) and trying to get it to do something out of the ordinary means you have to fight the application tooth and nail.

Fortunately SharePoint has several means of integrating transactional data into it.

First off (if you have the more expensive Enterprise licence) you have the Business Data Catalog that allows you to import database values that will appear similar to list items.

If you do not have the Enterprise licence, I can recommend either custom controls/webparts or the Data View Web Part to allow that data to be "shown" on the relevant pages within SharePoint.

In summary: You will be setting yourself up for a lot of uneccesary work by storing transactional data within SharePoint compared to other application designs hosting the data in traditional database applications and integrating to SharePoint.