0

I am very new to Sharepoint, please pardon my ignorance.

I am tasked with assembling a database for 30+ users, the database has many tables, forms for input, queries and reports which include graphic charts. The database also needs to have alerts based on dates within the database, approval emails etc. It is a fairly complex database which will require some code to drive some of the functionality.

I have access to a sharepoint team site, however I am only allowed admin access on the team site, not the farm or server.

My question is, can I build such a complex database for deployment on a team site with limited admin capability directly on the sharepoint team site? If not, would Visual Studio be the best development platform?

I have done some very minor testing, and I can create tables in Access, then upload them as lists into our sharepoint team site.

Maybe create all of the tables and relationships in Access then convert them to lists on the team site and then use Visual Studio to create the necessary forms and reports?

Or stay away from Sharepoint altogether and just build the database in MS Access and put it on a network drive?

1

MS Access and put it on a network drive, in 2014 ? Oh c'mon (publish it as a Web database with Access Services, if anything).

Kidding aside, what you described is exactly one of the main functionalities of SharePoint. Since you didn't specify what version and edition of SharePoint you have, I'll base my answer on what I know best, that is 2010 Standard/Enterprise. Let me dissect your requirements in order to see if SharePoint can actually suit you well:

  • 30+ users: that's a ridiculous small amount for SharePoint, even for a single-server installation
  • many tables, forms for input: a table in your DB terminology roughly* corresponds to a list in SharePoint. Forms for input are a native OOTB functionality (for every list, you get a new form, edit form and display form automatically created). *I say roughly because, and make sure you really understand the implications, SharePoint is not a relational database.
  • reports which include graphic charts: Reporting Services and/or chart webpart + performance point services (these latter two only on Enterprise)
  • have alerts based on dates: according to the the actual requirement, can be accomplished with either workflows or custom timer jobs
  • will require some code to drive some of the functionality: too generic a description to prefigure a solution, but more on this later on

Now, for the constraints you mentioned:

  • I am only allowed admin access on the team site: that's a common scenario and a good thing let me say. Developers should usually never have access as farm admins to a production environment. They are supposed to package a solution and hand it to the IT guys who, hopefully, know how to install it in production. You, as a developer, will have a full SharePoint installation on your dev machine, where you can develop and test without compromising or disrupting the production env.

Will you be able to build such a complex database for deployment on a team site with limited admin capability directly on the sharepoint team site? It depends on how complex the functionalities that you foresee will require code actually are.

Fairly complex SharePoint solutions can be built with a range of different tools such as (listed in order of what I consider their level of complexity):

  1. in browser customization
  2. customization done with SharePoint Designer
  3. client-side code (with the SharePoint Javascript client side object model)
  4. event receivers
  5. custom webparts
  6. application pages
  7. custom timer jobs
  8. custom webservices

Would Visual Studio be the best development platform? Referring to the previous list, made exception for 1,2 and 3, Visual Studio not only is the best, but actually is the only platform you can use to develop such artifacts.

Maybe create all of the tables and relationships in Access then convert them to lists on the team site and then use Visual Studio to create the necessary forms and reports?. I would suggest you stick to the web interface and SharePoint Designer as long as your requirements permit it and you only resort to Visual Studio when the boundaries imposed by their limited capabilities are too narrow for your actual scenario. Creating lists in SharePoint Designer is far quicker than in VS, moreover tables relationships don't necessarily map directly to lists relationships, because, once again, lists are not tables in a database sense.

Or stay away from SharePoint altogether? As a final advice, I would suggest that you get your hands dirty with SharePoint and acquire some experience in its basic features, in order to make yourself an idea of what its strengths and limits are. That's the only way if you want to make an informed decision on whether or not it's the right choice for you and your specific scenario.

| improve this answer | |
  • Thanks for the detailed response, for clarification Sharepoint is deployed on our enterprise for 16,000 users, groups of users (departments, ours is 30 members) are given a Team Site, with a group member(s) as an admin over the Team Site, I am one of the admins over our Team Site, however have had zero Sharepoint training, and very little time playing with Team Site. – Daniac Feb 2 '14 at 14:22
  • I think but do not yet know for sure, that my access is limited for building apps, or putting ASP.NET web forms, or pages up on the Team Site. I am trying to build this system with as little IT involvement as possible as with such a large organization, involving IT turns a 3 month project into a 2 yr project that is not exactly what we wanted. – Daniac Feb 2 '14 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.