The Wrong Platform

So I've made my decision, I think it's the wrong platform. Developing on SharePoint seems like a nightmare and for this project I would have to bend the platform to suit the needs of the system. There's plenty of resources out there where people talk about joining SharePoint Lists and manipulating Lists using Views and Web Parts but it's all unnecessary coding to get something simple to work! I can't guarantee the performance of the application or if it could be further developed due to the restrictions with storing data in SharePoint. Storing unrelated data with a 2000 item cap is bad. The project could not go from prototype to commercial release using SharePoint. To me SharePoint is aimed at people who can't code and just want a simple team website.

Sure it'll save me time as I don't have to code a user database or any lower level code but at the price I can't develop what I want, I'm restricted. It'll save time with testing too but I can see it getting messy.

I'm left scratching my head why SharePoint clumps information into a List and you can't use SQL. It's pointless having a system like that because there is so much power with SQL, I just don't know? I've read so many blogs and articles about developers constantly coming up with workaround for their SharePoint site and I don't want to be one of them. Also so many people frustrated trying to import a database into SharePoint.

I've come to dislike SharePoint without even getting stuck into it. Why use SharePoint when I can use PHP and MySQL. There are probably situations where SharePoint is a great idea but for this project it's not.

First Impressions

I'm just finished college and I got a research position with a company called BH Consulting. I'm so happy because it is difficult to get a job in this climate, especially one that you want. Anyway I've been asked by the company to build a web application but to develop it on the Microsoft SharePoint platform. My background in college was developing in Java with some C but I've never developed on a Microsoft platform. So I'm looking at ASP and C# and thinking it's not that dissimilar to what I was doing with Java and the syntax is not too bad, this is going to be okay (famous last words!).

At first glance SharePoint looked like a great idea and a powerful platform to develop on. But I did have some concerns, one of which was the fact that lower level coding has been taken away from developers. The idea being products and solutions can be developed quickly and easily. You don't build a website from scratch using ASP on SharePoint; instead you use ASP to extend SharePoint sites. This is fine using templates and extending them for a company that wants to create a space where people can work on a document or a task list or a wiki or something, but can the SharePoint platform be used to develop a really powerful web application? This is what I have to figure out; this is why I've been hired into a research position. Can it be done and if not what would I recommend.

With this project, and I suppose with any project, the developer needs to know what the client/boss requires from an application, what is their vision essentially. So I gathered information and I've been building upon a document while I'm waiting on the software I need on my machine here in the office. One of the conclusions I've come to is the database is the driving force behind this application and it needs to be designed and implemented to a high standard. My opinion is the application needs to use the concept of a relational database. After all, relational databases have been tried and tested and they work for powerful and demanding web applications.

So, logically I thought I might as well jump in and start designing a relational database. But... there's a bit of a problem. SharePoint does not support relational databases. What I mean by this is you cannot write SQL when developing for SharePoint and you cannot implement any relational database using the SharePoint platform.

There are options though, I could design and implement a relational database on an SQL server and import it into SharePoint. This does mean I need an SQL server on top of the other software for SharePoint and anywhere this application rolls out needs an SQL server. This may or may not be a problem, but there can't be any uncertainties in this solution. Another concern is I don't really know how well SharePoint interacts with an external database?

Ideally I'd just like to use the SharePoint platform and nothing else, so I was looking at SharePoint 'Lists'. Lists resemble tables in a database with columns and rows and you can add different data types, but, and this is a big one, -Lists don't relate to one another like tables in a relational database do. To get lists to relate to one another you have to write things called 'Web Parts'. At this stage I really don't know how good a solution this mixture of Lists and Web Parts will be? Also Lists only support up to 2000 items, not good when the database grows.

I'm starting to think SharePoint is fine for simple, unimaginative team sites using templates and clumping data here and there. Fine if all you want to do is something simple but for something that is specific and requires the power of a relational database back end, then SharePoint can't replace the power of current web technologies.

Bottom line is;

• 
  
  Will an external relational database work well with SharePoint and if it does will the use of an SQL Server cause problems when the product rolls out?
• 
  
  Will Lists and Web Parts be powerful and dynamic enough to get this job done?
• 
  
  Will it be the case where ultimately SharePoint is simply the wrong platform?