3 ms·

The irony for me is that SQL is the language that stood up the test of time the most. All other are/were gamble. Obviously it's not fit for all domains, since

The irony for me is that SQL is the language that stood up the test of time the most. All other are/were gamble. Obviously it's not fit for all domains, since it's a DSL for data management, but I'm often tempted to push as much business logic into the DB with PL as I'm allowed to instead of having to do things in the application code itself, and it paid off many times, as I have rarely seen a project moving from a database to another, while application code is often rewritten in many different languages for no other reason than management's whims. I probably saved some businesses millions of dollars in code porting/rewriting/migration. > The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk. In my experience, the biggest issue is the complete lack of code documentation, as organisations relies on a handful of developers to maintain their codebases and when these developers retire, suddenly, nobody can understand an architecture.

scarface74 7y ago
I actively avoid companies that put all of their logic in the DB. It’s harder to version control, harder to unit test, much more work to rollback. You can’t keep it in sync with the source code etc. I can’t just switch branches and know the state of the system at the time the branch was created.
- throw_m239339 7y ago
  You're making good points. First, I'm talking about a PL "middleware" layer than does not necessarily involves restructuring the data itself (basically, instead of querying tables or views, you query stored procedures or functions). When it comes to version control, wouldn't a migration system suffice to assess the state of that layer? As for unit testing, I kind of agree, it's possible though, like any other programming language.
  - scarface74 7y ago
    That doesn’t help. You can’t imagine the times I see Get_Customer_1 Get_Customer_2 Get_Customer_3 As far as version control, if someone does make a change to the unversioned “Get_Customer” and I want to switch branches. How do I make sure all of the stored procedures are in sync?
    - AmericanChopper 7y ago
      This is pretty much my experience with stored proc codebases too. I do consider SQL to be a very simple language, but store proc codebases tend to become incredibly complex. Finding an engineer that can maintain SQL code is very easy. Finding one that can maintain a particular maze of 1000+ stored procedures, views, functions, table triggers... is a completely different question.

scarface74 7y ago

I actively avoid companies that put all of their logic in the DB. It’s harder to version control, harder to unit test, much more work to rollback. You can’t keep it in sync with the source code etc. I can’t just switch branches and know the state of the system at the time the branch was created.

throw_m239339 7y ago
You're making good points. First, I'm talking about a PL "middleware" layer than does not necessarily involves restructuring the data itself (basically, instead of querying tables or views, you query stored procedures or functions). When it comes to version control, wouldn't a migration system suffice to assess the state of that layer? As for unit testing, I kind of agree, it's possible though, like any other programming language.
- scarface74 7y ago
  That doesn’t help. You can’t imagine the times I see Get_Customer_1 Get_Customer_2 Get_Customer_3 As far as version control, if someone does make a change to the unversioned “Get_Customer” and I want to switch branches. How do I make sure all of the stored procedures are in sync?
  - AmericanChopper 7y ago
    This is pretty much my experience with stored proc codebases too. I do consider SQL to be a very simple language, but store proc codebases tend to become incredibly complex. Finding an engineer that can maintain SQL code is very easy. Finding one that can maintain a particular maze of 1000+ stored procedures, views, functions, table triggers... is a completely different question.