Sharepoint webservices

Question

I have a couple of Sharepoint portals (Sharepoint Portal Server 2003 + SQL Server) running and they should both share some commom data. I was planning on working with two separate lists, and build a web app that will be responsible for updating them both throught the WSS Lists Service (">http://server/ vti_bin/lists.asmx). I'm wondering if that's a commom practice? Should I be concerned about the scalability of such solution? - the list should grow at a rate of ~3000 records per month.

Sorry for the poor title, I couldn't think of a better one.

Answer 1

If i understand correctly the web app you will be building is NOT a SharePoint web application, simply an ASP.NET web app that will call into the SharePoint to update lists with data presumably collected by your application.

This is a perfecty acceptable scheme, I think its exactly what the list web services are intended for.

The only trickiness you may run into is if you have to back-haul data from one of the lists back into your webapplication. Bi-directional synchronization is always a sticky wicket.

Answer 2

You should definitely be concerned with scalability. In WSS v3.0 land you can only (supposedly) store 2000 list items per container (aka folder). A folder counts as a list item.

If you nest 2000 items per folder you can potentially scale into the millions, but still it's an awkward way to store data.

You can still pull all the items out, flattening any folder hierarchies that you've created to help you scale with some CAML, but once again there's ways of querying large lists that scale better. I would suggest reading the resources amalgamated here by Joel Oleson.

I'm sorry I couldn't find more specific documentation, but I doubt lists will scale any better in SPS 2003.

Answer 3

The new recommendation is 3000 per container as Microsoft updated in this white paper. This isn't actually a hard limit. It is just the maximum you can store before seeing a significant performance hit. With that many items, you will definitely want to come up with a strategy of splitting your list items into multiple folders.

Here is Microsoft's official link on planning for software boundries although it hasn't been updated since the release of the white paper.

Answer 4

As Corey mentions, the 2000 (or 3000) items per folder is not a hard limit, but just a recommended limit. I believe it is really 2000/3000 items per folder or index. So, you can set up indexes for your columns as well and if you just have 2000 items or less per index value than you are within the recommended range as well. I have had 40k items before without folders and it can still perform.