In our organization, we have several databases. Each of them has lots of schemas with tons of packages, procedure, functions and so on. Now, I wonder what approach is best in terms of organizing those objects in a git repository. Should I have repositories based on schemas or application they're used by? There are lots of objects across different schemas that are used by multiple applications. So if I want to organize them by applications, then some objects will have to be in multiple repositories, which will obviously lead to having to update one object several times in different repositories. On the other hand, although keeping them by their schemas might sound a better idea, that way I won't have much clue about where these objects are used.

closed as unclear what you're asking by gnat, Thomas Owens May 25 '18 at 21:19

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    I cannot answer, sadly. I always had one database used by only one application. If multiple application need to work with the same data, it is preferable to implement a Webservice in front of the database and have that used by the other applications. Solves your issue and brings tons of flexibility – marstato May 25 '18 at 8:42
  • 2
    I did not downvote for now, but asking the community for the "best" approach to organize some software pool they don't know does not look like an answerable question to me. There is no "best", "one-size-fits-all" solution to it, and we can only guess how big or unstructured the mess is you have to deal with. Maybe I write an answer anywhere, but expect it to be only to be a rough guideline. – Doc Brown May 25 '18 at 12:32
  • 2
    Nobody is obligated to explain their downvotes. To the contrary, it is your obligation to become familiar with each of these sites and their culture and scope before posting here. Oh, and what @DocBrown said – Robert Harvey May 25 '18 at 15:28

Organizing by schema is the approach I would take. We use a similar layout at work, and I feel it just makes sense to have the same structures/navigation in source control as see in my PL/SQL IDE.

This also allows us to easily package up an entire schema into one versioned sql script that we can deploy to our various environments, which works well for our processes, but YMMV.


We usually organized by schema or group of related schemas, or used a monorepo.

I'd go with a monorepo unless there are serious concerns that prevent that, e.g. access rights isolation, or a colossal scale, and a pull takes many minutes. When splitting, I'd try to come up with as few repos as possible. Since you're using git, stepping on other teams' toes is not a concern.

Things that need to change in concert should be in the same repo and be able to change in the same commit. I would definitely not split a schema between two repos.

Things that need to be deployed together are easiest to keep in the same repo.

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