-1

I'm re-organizing a collection of disparate solutions into new BI solution in Visual Studio 2015. The resultant solution will contain a SSRS project, an SSIS project with BIML and two SSDT projects under GIT source control.

The SSDT projects will act as partial projects in the solution an only have the non-schema database objects related to the BI solution. (e.g. stored procedures, functions, views and synonyms).

The schema-based object of the databases will be in a separate SSDT project under GIT source control.

Is this considered best practice?

Derrick Bell
  • 2,615
  • 3
  • 26
  • 30

1 Answers1

-1

This is an opinion based question, so it is likely to get downvoted, criticized or no response.

The answer is that it depends on what works best for you. For me, no, all projects should be separated into their own solution. This makes things more manageable - there is nothing worse than one solution that tries to do it all. Plus, you get the advantage of being able to bolt solutions together in different combinations. Not to mention the fact that it takes time for solutions to open while Visual Studio validates the entire solution.

Be careful.

J Weezy
  • 3,507
  • 3
  • 32
  • 88
  • In a report solution will have rdl objects, but would you have to open another solution to view the stored procedures or views related to that project? – Derrick Bell Aug 03 '18 at 19:47
  • @Renegrin Not that I am aware of. Your two options for managing stored procedures in a report are either embedded data set within the report or as a shared data set within the project. I believe it is best practice to store report source queries as stored procedures on the server and then reference them as stored procedures that way you can make changes to the query without having to re-deploy the report. – J Weezy Aug 03 '18 at 20:42
  • I was hoping the solution would provide the context for use of the stored procedures and manage them in source control. Otherwise, I'm opening one or more other solutions to check them out in version control as I make changes. Thoughts? – Derrick Bell Aug 03 '18 at 21:27
  • @Renegrin Sounds like you want to keep everything together. So do that. You asked for advice on whether that was best practice or not. As I previously said, I do not think it is. On that vein, save the stored procedure in a separate *.sql file and check that into source control. Within source control, you can figure out how to logically group everything together. Trying to do all of that in a solution is going to bloat your solution and solutions were not designed with that intent in mind. – J Weezy Aug 03 '18 at 21:43