Problem Solvers: Inside the Stack w/ Tiger Data

So everything that we're doing today has been built by, it's been orchestrated by me from the use case working my way back.

So I started, I put myself in the position of like a plant engineer.

who wants to starts with a use case.

And the use case would be something to this effect.

I've got all this, I've got this sensor data.

I've got all this telemetry data.

I've got a hundred tags changing once a second, and I've got it.

And I want to historize that.

And most people, when they first get started, they don't buy a historian.

They, you know, the most common one is they, they buy KEP server EX and they use the transaction logger to connect to a database.

And they basically just, one one row for every for every tag change in a day.

Are you calling me

out?

Basically all of us do that and then eventually you get to a point where I need something more performant and really that point is basically 7 days like you can.

You can use a SQL database.

To show you an hour's worth of data or 24 hours and it's pretty performant when you move the charts around.

move the charts around, the charts will build themselves, right? It's just not that much data.

Now, that's assuming you're selecting just a, you know, you're doing a straight select statement.

You're not doing any math on the data or anything.

You're not doing aggregation.

You're just saying, go get these records in order, order them by the timestamp, and then put them on a chart.

Okay, and let me see what the trend is.

That's normally the very first use case in any type of historian.

And everyone always seems to start on the transaction logger side.

Right.