Re: Are stored procs "hiding functionality"?
Tossing my two cents in...
Personally, I prefer to not use stored procedures, because I haven't figured out how to write unit tests for stored procedures. (Note: I'm not asserting that it's impossible to unit test stored procs, but just saying I don't know how to do it.) I'm a Java guy by training, and a Groovy fan these last few years, but truth is, I don't sling that much code anymore. But what I teach the teams I work with in my role as ScrumMaster and/or DevOps Dude is that all code should be unit tested.
I also echo what Scott said -- All code should be managed in the same source repository, and all deployments should be handled the same. For deploying updates to the database, I currently use and recommend Flyway. When used along with Maven/Gradle as a build tool, it's just another CLI arg: ./gradlew clean test flywayMigrate.
Personally, I prefer to not use stored procedures, because I haven't figured out how to write unit tests for stored procedures. (Note: I'm not asserting that it's impossible to unit test stored procs, but just saying I don't know how to do it.) I'm a Java guy by training, and a Groovy fan these last few years, but truth is, I don't sling that much code anymore. But what I teach the teams I work with in my role as ScrumMaster and/or DevOps Dude is that all code should be unit tested.
I also echo what Scott said -- All code should be managed in the same source repository, and all deployments should be handled the same. For deploying updates to the database, I currently use and recommend Flyway. When used along with Maven/Gradle as a build tool, it's just another CLI arg: ./gradlew clean test flywayMigrate.
