3 ms·
> 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.ti
by 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.