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):
- in browser customization
- customization done with SharePoint Designer
- client-side code (with the SharePoint Javascript client side object model)
- event receivers
- custom webparts
- application pages
- custom timer jobs
- 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.
