Hacker News Reader

Comment by gaius | Hacker News Reader

Unfortunately this is common, but as a "DBA" I can tell you right now: it's inconsistent for a developer to sneer "databases don't scale" and yet advocate the use of an ORM that generates bad, bad SQL! When speed matters, you have to get the compute and the data as close as possible. You can slurp it all into the application and work on it there, or you can just do the computation in the database, which is actually easier, and more efficient.

FWIW I work on a trading system that happily handles thousands of commits/sec, in Oracle, along with complex calculations of exposure and the like.

View on HN

I agree there is a point when optimization is required. At the time we were building a new product that had rapidly changing requirements and few users. So you can see my frustration when days of man hours where spent on this database.

You say the DBA "showed" that SPs were faster. It's hard to argue against actual timings. Why shouldn't he have had his say?

Because it was also shown in several project's before and the current one that writing these custom SP's and using autogenerated SP's added huge amounts complexity and development time to our application.

Which again was still being built and had no need to be a high performance machine. In fact none of the products that the company served up needed to be high performance. These guys were smart and bored and built huge monolithic systems full of complicated approaches to simple problems.

Edit: Further more nobody wanted to work with this guy on the team. He was an "expert" on everything and ran every single conversation about anything, including areas he had no experience in, into the ground because nobody's opinions were valid because he clearly knew everything. /rant

Well, if you were a PL/SQL dev, you'd be making the same complaint about the complexity of J2EE. I've no experience of working on systems where performance wasn't an issue :-)

> When speed matters, you have to get the compute and the data as close as possible.

And when scaling matters, you often need to do the opposite. And scaling is often more important than speed.

Ermm, that's nonsense. You can move the compute into the database (stored procedures) or you can move the data to the compute (caching - and deal with cache invalidation yourself). There is no situation ever in which you would deliberately seek to make them as far apart as possible.

Not necessarily nonsense: figuratively, you can (and should in many cases!) be putting as much of the data as possible, as far away as possible from your code with divide and conquer to work on only a fraction of it.

But anyway, that's what indexes are for in RDBMS, so you still have a point, even figuratively :)

> You can move the compute into the database

Yes, often doesn't scale because the database is an extremely limited resource that generally doesn't scale horizontally.

> or you can move the data to the compute

Which is what I said, which allows you to scale computation horizontally.

> There is no situation ever

You just named one, however I see where you're misinterpreting me or I you; when I said do the opposite, I meant move the computing away from the database.

Reply on news.ycombinator.com