Real-time report VS Application

It is very often that we report developers get requests about "real-time" reports.  I don't know about you, but I cringe every time I hear about this.

For some people, "real-time" report means I have a report that executes a query in the database to get result back.  But when you think about it, if you answer "yes" to any of the following questions, you don't really have a real-time report:

  • Is your dataset cached on the report server?
  • Is the query result cached on the database server?
  • Does your source data come through some kind of ETL process?  In other words, is your data processed (original raw data lives somewhere else)
  • If your data is the raw form (directly from a sensor, for example), does your sensor (or other data gathering instrument) poll data on a timed basis?

And even if you don't answer yes to any of those questions above, you might not be able to get your report to be "real-time" if there is high network latency, high volume data traffic so that transaction lock is needed, lack of report server memory to process quickly, lack of end user UI to render the report quickly, any number of things.

Granted, my definition of "real-time" is very strict.  I consider watching a game on television not real-time because of delay in satellite transmission, intentional program delay, and possible buffering depending on the tool you are using.

Even if I can let go of the strict definition, every time I hear the report request being "real-time", my first reaction is a question back at the user: "what is it that you are trying to achieve by using a real-time report?"  Because too often I'll get into these kinds of conversation:

  • How often do you run the report?  Once a day (the most I've ever gotten was once an hour)
  • I want to be able to change some source data to respond (uh, then you are not asking for a report, but an application)
  • I want the data to reflect the current data.  (I can make a single sensor reflect data change almost instantaneously, but would you need the summary data to change every 3 second?)  Don't even need that.
  • I want a screen that tells me about a problem immediately.  (So you don't want a report that you have to log in to see, I can build you an alert system and alert you via email or text messages)  GREAT!
  • I want a report that tells me how my group is doing.  (How about a dashboard type of screen that polls the data every 15 seconds?) It should be good enough to do every 5 minutes on my phone, and maybe every minute on that big TV in the team's room.

My point is, when the end user makes a "real-time" request, there is usually something she/he hasn't explained yet.  It is our job to find out what that additional requirement is and make appropriate recommendation.

Print | posted on Thursday, March 20, 2014 10:18 AM


No comments posted yet.

Your comment:


Copyright © Kevin Shyr

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski