7 ms·

Why are these practices not common with web developers? What’s held them back in recent years using it?

by iddan 4y ago

btown 4y ago
IMO the lack of a Terraform-esque ecosystem of tools around declaratively managing database-objects-as-infrastructure, and understanding how a rollout of a change would be planned, has historically been a big issue. If I'm choosing where in the stack to declare some new business logic or type constraint, I can trivially check that into Git if it's running on an application server, and most frameworks' ORMs can handle column-level migrations. And if I make a mistake, I can push a change that declaratively says what my function signature or DDL should be; it's one of the first things taught to new developers. Terraform extended this mentality to infrastructure, and it was gamechanging. But there are far fewer tutorials and best practices on how to, say, maintain a library of Postgres functions, types, and stored procedures that can be iterated on. I'd venture that most people have no idea how powerful their databases can be.
progmetaldev 4y ago
I think most web developers just do not understand SQL well enough to take advantage of these types of features (and if they do, they still may be sticking closer to "standard" ANSI SQL, or may just not be up to date on newer features). Unfortunately, lots of web developers don't get past their ORM abstraction into what is occurring behind the scenes and how to make use of the full range of their database's features.
- LunaSea 4y ago
  The tooling ecosystem for databases is also terrible. Bad support for testing, for version controlled schemas, language types, etc. This is the reason for the spread of ORMs and similar abstractions to hide this lack of support.
weird-eye-issue 4y ago
Way easier handling this in the application code. If I had a developer join my team then commit this into the codebase rather than just using the ORM that everyone else is familiar with they would be fired UNLESS there was a very good reason for doing so
- cgh 4y ago
  Easier, slower, more error-prone. Also, you should consider implementing code reviews rather than just firing people who commit code you don't like.
- doctor_eval 4y ago
  I love working directly in plpgsql, it makes it possible to perform all the database logic in the database, effectively presenting a domain-specific API to the world. This api is then available to any SQL user. It’s like creating a built in CLI for your data. Putting logic directly in the database is much faster at runtime, doesn’t require redundant entity definitions, is substantially more likely to detect schema problems, and is way easier to test. And it removes the dependency on a specific language and toolchain. Your logic is accessible by everyone. Unfortunately, the tooling around managing this stuff is not great. The language is a bit boring; idiomatic upper case is the first thing I get rid of. But it’s the best tool for the job. Far from being “way easier” in application code, plpgsql reduces LOC, improves performance and removes dependencies. If someone on my team ignored all of these benefits, well, I’d explain it to them and show them examples until they “got it”. Way easier than firing them.
  - icedchai 4y ago
    Very few people know plpgsql. Like all stored proc languages (Oracle PL/SQL, etc.) it looks and feels like something out of the 80's. It's annoying to deploy, annoying to debug, annoying to test. Many developers today barely know SQL.
    - doctor_eval 4y ago
      It’s easy to make it feel more modern (select ffs from stop_using_all_caps). But it’s an ideal DSL for data manipulation. It’s not particularly annoying to debug - there are logging, and even single step debugging tools available - and it’s so much easier to test than writing unit tests to do the same thing. I agree it’s painful to deploy, but as I’ve discovered this is a tooling problem; it’s not at all intrinsic to the medium. It’s certainly possible to create tooling to make it easier, and who knows? Maybe I’ll have something to show HN one day. > Many developers today barely know SQL. If true - a very big if - it’s an inditement of the industry and the incentives we use, not a reason to avoid something that makes code faster, safer and smaller. Objections to using these languages are a lot more about willingness to learn and try new (old) things, than they are about the capabilities of the platform.
oliverrice 4y ago
I think there are a few things: 1) Its only been a few years since the trend of testing on sqlite locally and running postgres in production went away in favor of postgres everywhere (probably thanks to docker). That prevented using any feature that wasn't equally supported by both. 2) There's definitely a knowledge gap, and not just among developers. The features are most useful for building rich applications, so even DBAs didn't have much incentive to use them prior to tools like supabase using the database as the data model source-of-truth. 3) Companies are increasingly deciding that data is their competitive advantage and interest in data integrity is growing. Database constraints are unparalleled at that because they can't be sidestepped
RedShift1 4y ago
I think most webdevs see databases as dumb datastores.
dventimi 4y ago
I blame the Apple II computer.
- heywhatupboys 4y ago
  no to forget: Turing's seminal paper
  - dventimi 4y ago
    Perhaps you're joking, but I'm not. The personal computer revolution began in earnest with the Apple II in 1977, joined by the Commodore 64 in 1982. Gen-X boys shoved Gen-X girls aside, shoved the computers into their bedrooms, and 15 years later were at the right place and the right time to shove an Algol-based tech stack onto the center stage of the dot com boom. SQL was a necessary evil held at arms length behind ORMs as fear, uncertainty, and doubt rapidly took root. It's taken decades, but finally, mercifully, the Gen-X priests of procedural programming are losing their grip and we're just starting to emerge from the Dark Ages of all this superstitious nonsense about not putting business logic in the database. It's been a long strange trip, but it's never too late to study the classics. After all, they never really go out of style.

Why are these practices not common with web developers? What’s held them back in recent years using it?

by iddan 4y ago

Why are these practices not common with web developers? What’s held them back in recent years using it?

IMO the lack of a Terraform-esque ecosystem of tools around declaratively managing database-objects-as-infrastructure, and understanding how a rollout of a change would be planned, has historically been a big issue. If I'm choosing where in the stack to declare some new business logic or type constraint, I can trivially check that into Git if it's running on an application server, and most frameworks' ORMs can handle column-level migrations. And if I make a mistake, I can push a change that declaratively says what my function signature or DDL should be; it's one of the first things taught to new developers. Terraform extended this mentality to infrastructure, and it was gamechanging. But there are far fewer tutorials and best practices on how to, say, maintain a library of Postgres functions, types, and stored procedures that can be iterated on. I'd venture that most people have no idea how powerful their databases can be.

progmetaldev 4y ago

I think most web developers just do not understand SQL well enough to take advantage of these types of features (and if they do, they still may be sticking closer to "standard" ANSI SQL, or may just not be up to date on newer features). Unfortunately, lots of web developers don't get past their ORM abstraction into what is occurring behind the scenes and how to make use of the full range of their database's features.

LunaSea 4y ago
The tooling ecosystem for databases is also terrible. Bad support for testing, for version controlled schemas, language types, etc. This is the reason for the spread of ORMs and similar abstractions to hide this lack of support.

weird-eye-issue 4y ago

Way easier handling this in the application code. If I had a developer join my team then commit this into the codebase rather than just using the ORM that everyone else is familiar with they would be fired UNLESS there was a very good reason for doing so

cgh 4y ago
Easier, slower, more error-prone. Also, you should consider implementing code reviews rather than just firing people who commit code you don't like.
doctor_eval 4y ago
I love working directly in plpgsql, it makes it possible to perform all the database logic in the database, effectively presenting a domain-specific API to the world. This api is then available to any SQL user. It’s like creating a built in CLI for your data. Putting logic directly in the database is much faster at runtime, doesn’t require redundant entity definitions, is substantially more likely to detect schema problems, and is way easier to test. And it removes the dependency on a specific language and toolchain. Your logic is accessible by everyone. Unfortunately, the tooling around managing this stuff is not great. The language is a bit boring; idiomatic upper case is the first thing I get rid of. But it’s the best tool for the job. Far from being “way easier” in application code, plpgsql reduces LOC, improves performance and removes dependencies. If someone on my team ignored all of these benefits, well, I’d explain it to them and show them examples until they “got it”. Way easier than firing them.
- icedchai 4y ago
  Very few people know plpgsql. Like all stored proc languages (Oracle PL/SQL, etc.) it looks and feels like something out of the 80's. It's annoying to deploy, annoying to debug, annoying to test. Many developers today barely know SQL.
  - doctor_eval 4y ago
    It’s easy to make it feel more modern (select ffs from stop_using_all_caps). But it’s an ideal DSL for data manipulation. It’s not particularly annoying to debug - there are logging, and even single step debugging tools available - and it’s so much easier to test than writing unit tests to do the same thing. I agree it’s painful to deploy, but as I’ve discovered this is a tooling problem; it’s not at all intrinsic to the medium. It’s certainly possible to create tooling to make it easier, and who knows? Maybe I’ll have something to show HN one day. > Many developers today barely know SQL. If true - a very big if - it’s an inditement of the industry and the incentives we use, not a reason to avoid something that makes code faster, safer and smaller. Objections to using these languages are a lot more about willingness to learn and try new (old) things, than they are about the capabilities of the platform.

oliverrice 4y ago

I think there are a few things: 1) Its only been a few years since the trend of testing on sqlite locally and running postgres in production went away in favor of postgres everywhere (probably thanks to docker). That prevented using any feature that wasn't equally supported by both. 2) There's definitely a knowledge gap, and not just among developers. The features are most useful for building rich applications, so even DBAs didn't have much incentive to use them prior to tools like supabase using the database as the data model source-of-truth. 3) Companies are increasingly deciding that data is their competitive advantage and interest in data integrity is growing. Database constraints are unparalleled at that because they can't be sidestepped

RedShift1 4y ago

I think most webdevs see databases as dumb datastores.

dventimi 4y ago

I blame the Apple II computer.

heywhatupboys 4y ago
no to forget: Turing's seminal paper
- dventimi 4y ago
  Perhaps you're joking, but I'm not. The personal computer revolution began in earnest with the Apple II in 1977, joined by the Commodore 64 in 1982. Gen-X boys shoved Gen-X girls aside, shoved the computers into their bedrooms, and 15 years later were at the right place and the right time to shove an Algol-based tech stack onto the center stage of the dot com boom. SQL was a necessary evil held at arms length behind ORMs as fear, uncertainty, and doubt rapidly took root. It's taken decades, but finally, mercifully, the Gen-X priests of procedural programming are losing their grip and we're just starting to emerge from the Dark Ages of all this superstitious nonsense about not putting business logic in the database. It's been a long strange trip, but it's never too late to study the classics. After all, they never really go out of style.