Hacker News Reader

Comment by blablabla123 | Hacker News Reader

> 3. You can do a crap load of stuff with joins, procedures and CTEs once you understand it.

Yes, or you can skip that part and do the tricky part in an actual programming language ;) For instance in Haskell or JavaScript. There is then even a chance that the code is both fast and actually works. :D

I mean in the end this is just a cheap marketing trick to literally buy people into the platform. People can write it into their CVs. The whole Influx ecosystem looks great. Although the UI (Grafana) is slow as hell once there are enough Graphs in and if you need fail-over or scaling, you need to buy an expensive license.

Also already the existing query language is obscure and counter-intuitive.

View on HN

> Yes, or you can skip that part and do the tricky part in an actual programming language

But then

- you miss out the power of the query optimiser

- you have to transfer a lot of unnecessary data

- have a harder time to enforce consistency

- have a harder time to enforce access rules / security

There are good reasons to do as much as possible in the database and not in a programming language in the backend or even worse, the frontend/browser.

I don't think that follows.

Many of the optimizations you mention (for example the first two) may in fact be removing baggage that probably would not have been there in the first place.

> Yes, or you can skip that part and do the tricky part in an actual programming language

That works great up to a point but will not scale for environments that need to scale. I’ve worked on a number of systems where they implemented excel export or bulk import components and wondered why their application locked up after a few thousand rows.

Usually the developers turn around and blame their SQL engine for being deficient and then try Mongo or similar - not because it’s better necessarily but it allows them to continue working the way they want to (on application code).

Not to sound mean but the developer types who shy away from writing proper SQL queries also seemed to be oblivious to asynchronous programming techniques and using the right data structures in their code - indicating that they were generally less interested in finding the most efficient methods.

> Yes, or you can skip that part and do the tricky part in an actual programming language

Are you proposing pulling in an entire dataset into memory and post-processing it vs. creating efficient SQL to get what you need?

As crazy as this sounds, yes. Not the entire dataset of course, a selection of it and then tie things together on the fly.

I've seen a handful of systems (one of them I wrote myself :D) that did complex queries. In part and in certain situations this can be very efficient, no doubt. But what I observed is:

- dev-wise these systems become one-man-shows

- implementing feature over feature becomes exponentially slower with time

- initial performance is there but it turns into slow performance over time

I prefer to do things on the application side.

Sounds like you could benefit from learning SQL.

Just so you are aware, in reality all the points you listed are exactly the results of what you are describing.

It becomes a one man show because anyone competent is going to run away from that mess right away.

New features become exponentially slower with time because you are re-implementing some ad-hoc SQL implementation in JavaScript of all things.

Initial performance is fine on your device setup, but drastically slows down over time when you pull in more data and do more complex things.

As someone else pointed out, you could benefit from actually learning SQL. There is a reason it's used.

The Influx ecosystem actually offers https://github.com/influxdata/chronograf for graphing in stead of Grafana.

Reply on news.ycombinator.com