3 ms·
> I think this is just poor modeling. SQL is just fine for the work you're talking about. I'm as big a booster of good old SQL as anyone, but there's a lot to
by abraae 5y ago
> I think this is just poor modeling. SQL is just fine for the work you're talking about.
I'm as big a booster of good old SQL as anyone, but there's a lot to be said for more targeted time series solutions when it comes to sensors.
I'm working on a platform for monitoring water water tank levels. It slices Grafana and influxdb horizontally to share the resources between multiple users and multiple tanks.
The productivity of such a stack is high, when it comes to getting beautifully rendered, interactive graphs of e.g stacked water levels. And with influxdb flux language, you can write joins that join data from the time series database and the rdbms (for more reference data, like the names and calibration data of individual tanks).
Yes you can do anything with SQL but there's a reason for the presence of dedicated time series databases.
- void_mint 5y ago> I'm as big a booster of good old SQL as anyone, but there's a lot to be said for more targeted time series solutions when it comes to sensors. https://www.timescale.com/ https://www.timescale.com/ Sensors aren't really different from any other timeseries data. > The productivity of such a stack is high, when it comes to getting beautifully rendered, interactive graphs of e.g stacked water levels. And with influxdb flux language, you can write joins that join data from the time series database and the rdbms (for more reference data, like the names and calibration data of individual tanks). Your productivity being high with a given tech stack does not disqualify an alternative tech stack from having equally high (or much higher) productivity for equally trained users. > Yes you can do anything with SQL but there's a reason for the presence of dedicated time series databases. The reason you're describing is "marketing"
- abraae 5y ago> Your productivity being high with a given tech stack does not disqualify an alternative tech stack from having equally high (or much higher) productivity for equally trained users. Try implementing classic timescale features like down sampling in your straight RDBMS. Certainly you can do it, just as you can build a house with a hammer and nails rather than a nail gun. But you'll spend lots of time building undifferentiated infrastructure that you could have got out of the box.