How to handle database source in repositories of other applications?

Question

This may be more opinionated than I like, but please forgive me. I'm searching for a definitive answer.

I am using GIT, JIRA (Issue Management), Bitbucket (online GIT projects) and SourceTree (GIT GUI client) for a project that involves multiple cross-code and cross-platform segments.

My issue is specifically with how to handle database source control in relation to the applications that utilize said database and it's objects?

For example, let's say you have a web based tool that was developed to pull data from said database using stored procedures. Would the database stored procedures be stored in the same repository as the web application?

In another example, let's say the same web application just used basic SQL queries. But, the systems that prepared the data such as a complex ETL system, helped make it happen. Would the ETL system source code be in the repository too?

(Note: I am not referring to database changes to the data types, indexes or schema. I'm referring to SQL scripts, stored procedures, SSIS packages, SSRS source and even possibly OLAP cube frameworks that are stored in the service. But of course, are not members of a DRC or CSM system for control outside of developer control.)

I hope this isn't too broad. There is just very little documentation out there in handling relational database objects in relation to a application or related systems. Databases by themselves do not seem to be that popular for DRC and CSM systems even though they are a critical part of the puzzle.

Answer 1

Unfortunately, there is no definite answer to this question. Where to store part of your system (or where to draw the line between systems) is hight context dependent.

Some considerations that might help you to decide are:

1. Who is developing the code?
   If everything is created and maintained by the same team then it might be best to store everything together

2. At what rate is the code changing?
   If the code to show the data is changing rapidly, while the code to create the data is only changing sometimes it might be best to separate the two code-bases

3. How is the code deployed/run?
   If the deployment and running of various parts of a system is vastly different then it could make sense to store and handle them in a different way.

To link this to your examples, in the first situation I would probably suggest to keep everything together based on considerations 1 and 3. For the second example, all considerations together would suggest moving the ETL system to a separate repository.