Hacker News Reader

Comment by yuvadam | Hacker News Reader

Sorry, I call BS.

I might have just been lucky enough to always work at professional companies and startups where this kind of stuff can never happen.

But something tells me there is no reasonable way an SQL query can grow to these proportions.

View on HN

All the good techniques and technologies you use now? Yeah, those were invented because the way a lot of people used to do things was terrible.

I'm not old enough to have built systems like that, but I have inherited some for maintenance and debugging. That's not likely to be BS. Back in the day "do it in a stored procedure" was common advice. All the logic for untold applications and millions of lines of code lived at the database level.

Count yourself lucky perhaps to have entered the market when you did, but don't discount that you're standing on tall, sometimes ugly, shoulders.

Systems like that don't even have to be particularly old. I used to work on a system that started out as an Access database, and rather than doing things properly, the developers basically just translated everything into SQL statements and used ASP and COM+ on top of it.

It was a load of crap, but it still ran about 10x faster than what customers were used to, so they weren't complaining. Last I knew they were still running the same basic setup, and it's been 5 years since I worked there.

It's a good point. At one time the database was the application. Stored procedures and such were part of the application UI (as it were). At one time features were being added to database systems you could build command-line interfaces for the end-users. These days the database is mostly just used as a storage engine.

Not that I really care about "back in the day!" But it can be helpful to understand why certain things were done in a certain way. It seems like ancient history, but there you definitely will find some old code when you start working at companies that have been around for more than a few years.

There's still plenty of DBAs out there preaching "do it in a stored procedure", because in theory it lets them do things like changing normalization without affecting the application interface. (In practice, I've never seen happen that way.)

But in general, people did thing that way because there wasn't any common middleware or services interfaces. The RDBMS was the "app server".

Most of the stuff on Daily WTF comes from corporate America, often from places where the chief focus of the company is not technology/web.

Don't know what to say, other than it's not only possible, it's not all that uncommon. I can't speak to legitimacy of this particular entry, but the absurdity of it doesn't shock me at all.

Spend some time in the marketing or IT divisions of many Fortune 1000 companies, and you'll understand how Daily WTF is therapeutic for those who have to work in those environments.

I was once handed a database with four SQL procedures in it. Each procedure was 6+ pages of run-on PL/SQL. The picture in the original article is frighteningly close to what I had in hand at that point. Mostly nested cursors and imperative style programming munged into the proc.

I've seen other cases, none quite as bad as that one. It tends to be the result of giving a developer who hasn't had any formal training or experience with SQL a requirements doc without any supervision. If all you have ever done is normal imperative coding, you will not even know you are doing it wrong.

You can also find some weird SQL created by report generator tools.

I worked at a company that had a ton of business logic in stored procedures. Yes, queries can get ridiculously long. All of their queries were written by hand.

Why not? It's probably computer-generated. You can actually see the first page, and if you look at it, it uses nested SELECT statements. No one said it was smart, but it certainly is reasonable.

Automated query builders.

No one claimed it was reasonable. But it happens.

Reply on news.ycombinator.com