print Tutorial 4: Introduction to the Reporting System

Introduction

A common component of any large system is reporting. Whether these are customer reports such as new registered users, products sold, or popular items or tracking trends or system reports looking at errors and issues - there is a time when developers have to build and run a report. And then there are the never ending requests for "tweaks" or "can you just put it in XLS format" etc.

As anyone will tell you, writing reports is tedious, time consuming and getting the data is only half the battle. Presenting it in a "nice" format can take just as long and one report is never enough. Many times the answer is to copy and paste the first report and change it as needed. Not a very good way to manage things: but when time is against you, there are pressing deadlines and there are other bugs that need attention, the temptation is there to do just that.

Scorpio aims to help here by including a set of basic classes that are geared for creating, running and writing reports. While this is not a complete system (further ideas will be discussed later), there is enough to get you going.

So what do we mean by "report"?

Lets begin by defining what we mean by a "report". After all we deal with reporting systems regularly (e.g. webstats, Google Analytics, daily log summaries etc). In the context of the Scorpio reporting system, a report is a re-usable class that aggregates and transforms a set of data to a specification.

Where this data comes from does not matter, all we care about is that it needs to be transformed in some way to make it sensible to an end-user. In most cases this data is going to come from a database (or multiple databases) but it could just as easily be downloaded from a remote server, from a SOAP request, in-fact any data source that PHP can connect to.

So a web runnable report?

No, not really. An important distinction to make here is that the Scorpio reporting system is intended to be used offline in a CLI environment. Why would that be the case? Well reports can be extremely system intensive, require a lot of memory and may take a long time to run. Because of these factors it is strongly recommended to never run reports in a web context - they can be, but it is not recommended.