Hacker News Reader

Comment by larodi | Hacker News Reader

but why? what would make you react at human ingenuity with shame and desire? is this something about you or something about them in particular? isnt the whole of HN about human ingenuity...?

are we to feel Taco Bell menu about it all, what am I missing?

View on HN

This is just a guess, but if the OP's reason is similar to mine, DBMSs should be reserved for managing databases and not implementing complex logic.

Why not? I think the main barrier is the programmers are not comfortable with recursion, rather than a technical limitation.

I’d hazard a guess that quite a few devs have at one point, been lumped with a db where someone pushed too much logic into it. Probably great for the one person who wrote it, and awful for everyone else.

Mystery triggers, unclear or badly managed stored procedures, opaque invariants. It’s not to say that all of these things are bad, but a certain level of DB complexity will naturally set off alarm bells for some devs.

One of the most eye opening moments in my junior dev career was when I found a really nifty way to achieve an operation using SQL alone and brought it to our VP (start up, small company size). It wasn’t esoteric, but used some SQL features not well-trodden by web devs. I thought I was the bees knees and this would be a clear demonstration of my sizable brain. He complimented the thought behind it, but immediately vetoed it as too complex for the majority of developers who would have to touch the code down the road. In hindsight he was completely right.

I don’t think this is a win. Cautioning against adding new technology to learn and maintain is one thing. But not using an effective solution in your toolset because it’s too hard is absurd.

Our Industry pretends solutions must be immediately understandable with common sense, without study or explanation. But nothing that actually matters does this (relational databases in the first place).

No other engineering discipline has this confusion. The world has complexity and it’s our job to understand it.

SQL tends to be very dense (more thinking than typing).

It is tedious to specify all that information (access, constraints, foreign key, cascading, views), but it’s all essential information you would end up specifying in another way.

In the past (why do I feel so old when I say this?), DBMSs WERE used to implement complex logic. Not just complex business logic, but even authentication, authorization, etc were implement with stored procs, embedded sql, native DB features.

The cycle in tech will shift from one side to another; last decade was a lot of no-sql where all this logic and implementation had to reside on the application side. I'm seeing a shift back to DBs again (e.g. supabase), and the reality is that it's probably a continuum somewhere in-between, depending on your requirements (as always, the answer is "Yes, but it depends").

Remember, these are all "just" tools.

SQL is like regex.

A small fraction of people bothered to learn how they work and know how and when to use them properly.

Everyone else just perpetuates a giant in-joke of “it’s black magic!”

I do line of business apps right now.

It seems to me that we have the abstraction inverted when it comes to ORMs, which is why so many experienced devs dont like ORMs (but can't really articulate why).

Here's my take, in the context of business logic:

The schema represents the business rules. The ORM papers over the DB so that the code doesn't have to match the business rules. Then the dev implements those rules again in code, but poorly.

If you simply skip the programming language using something like Postgrest you end up with a declarative structure of the business rules.

The first problem is that most developers would rather hunt a bug or perform a modification on a 30k Java or C# or python or ruby program than in 5k of SQL.

The next problem is that tooling for SQL is crap. It's declarative so good luck stepping through the logic. The dialects are all different so editors aren't great at spotting errors.

The last major problem is that changing it is hard - you can't simply change the schema and redeploy because migrations have to be made on the existing data.

All of these are surmountable in some ways, but they certainly ain't easy.

Doing LoB apps have opened my eyes a lot: maybe 99% of logic is shorter when expressed in SQL. Of course, that means that the only use of an ORM in this case is connecting to the DB, sending the query, and sending back results.

Reply on news.ycombinator.com