Comment by liontwist
3 months ago
Why not? I think the main barrier is the programmers are not comfortable with recursion, rather than a technical limitation.
3 months ago
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.