4 ms·

What is so hard to source control with stored procedures, I’ve writing them in text files for over 30years, version controlled in rcs, cvs, svn and git. No prob

by ako 2y ago

What is so hard to source control with stored procedures, I’ve writing them in text files for over 30years, version controlled in rcs, cvs, svn and git. No problem, it’s just the deployment automation that works a bit different. Also, oracle plsql is way better than ms t-sql, it mostly feels like pascal/modula2 with embedded sql statements.

dalyons 2y ago
yes, you can hack something together that keeps them in source control, and then some automations to run them in a CD way. But now your business logic change is half in application code, and half in sprocs, and you have a versioning and deployment coordination problem. Which you can work around too. But why? making deployments and debugging of buis logic hard for what end? Just keep all the business logic in your app code, then its deployed and tested as one artifact, and everyones happier. Also i hope you're not suggesting anyone pick up oracle for a new project these days :)
- ako 2y ago
  What do you mean hack to keep them in source control? They're just sql source code files, like any other source code you can simply commit to version control? Wouldn't advise anyone to use Oracle, but neither would i advise them to use sql-server. Usually Postgres is good enough, although oracle plsql is still nicer than postgres plsql (e.g, packages).
  - dalyons 2y ago
    i feel like i addressed this in a different subthread https://news.ycombinator.com/reply?id=40526231&goto=threads%3Fid%3Ddalyons%2340526231 https://news.ycombinator.com/reply?id=40526231&goto=threads%... > You can source control them, but then you have a deployment coordination problem. Often changes to business logic will be half in application code and half in the sproc, and you have to coordinate the deployment of that change. You have to somehow reason about what version of the sprocs are on your server. Add on that usually in enviroments that use sprocs, changes to them are gatekept by DBAs. Just write your business logic in application code.

by ako 2y ago

dalyons 2y ago

yes, you can hack something together that keeps them in source control, and then some automations to run them in a CD way. But now your business logic change is half in application code, and half in sprocs, and you have a versioning and deployment coordination problem. Which you can work around too. But why? making deployments and debugging of buis logic hard for what end? Just keep all the business logic in your app code, then its deployed and tested as one artifact, and everyones happier. Also i hope you're not suggesting anyone pick up oracle for a new project these days :)

ako 2y ago
What do you mean hack to keep them in source control? They're just sql source code files, like any other source code you can simply commit to version control? Wouldn't advise anyone to use Oracle, but neither would i advise them to use sql-server. Usually Postgres is good enough, although oracle plsql is still nicer than postgres plsql (e.g, packages).
- dalyons 2y ago
  i feel like i addressed this in a different subthread https://news.ycombinator.com/reply?id=40526231&goto=threads%3Fid%3Ddalyons%2340526231 https://news.ycombinator.com/reply?id=40526231&goto=threads%... > You can source control them, but then you have a deployment coordination problem. Often changes to business logic will be half in application code and half in the sproc, and you have to coordinate the deployment of that change. You have to somehow reason about what version of the sprocs are on your server. Add on that usually in enviroments that use sprocs, changes to them are gatekept by DBAs. Just write your business logic in application code.