2. The main ideas behind this tool

The purpose of this reporting tool is to facilitate the work for somebody who, like the author, frequently uses SQL for analysis, investigative purposes, migrations, coding, etc.

Frequent SQL users typically tend to build collections of useful and reusable SQL queries, which are successively improved until they become a sort of reports without user interface or “magic” scripts to solve problems. At some point this collection matures to a bunch of pretty good SQL queries which have to be just slightly modified manually to catch the information in the needed context. But on the long run this manual modification work becomes less and less satisfactory. At the end you either discard or comment out the manual changes of the day in order to keep the good SQL query generic or you increase the number of the stored queries and of the hassle of maintaining the overview.

At this point the idea came up that a database reporting framework would be useful, which runs these good SQLs in a defined order and like “out of thin air” it restricts the query results to a certain context of my interest, all this without the need to modify the generic SQLs.

Such a reporting framework would then necessarily include a definition part, in which the user needs to specify what he is interested in. But this framework should not constrain the user to specify right before start all the criteria he is interested in. First to avoid work as much possible, and then also because when someone does an investigation he usually finds something new on his investigative way, which leads him to revise the next step and/or the criteria of interest. Therefore this reporting framework should start with a minimal set of very generic criteria and then, as it executes more and more SQL queries, it should collect the new criteria of my interest from the previously retrieved information and apply these criteria in the needed way.

In few words this report framework should be able to contextualize the results on an SQL query based on the information he retrieved till that point from other SQL queries and add all or some (or none) of the newly retrieved data to the context, which is then used for the next queries. The "role model" for this contextualization of retrieved database information is a logical work we are doing naturally when using the language. What kind of "naturally" happening work is intended here exactly?

First, a statement is told and understood in a context of generic concepts, regarded by author and audience as common sense. Second, a statement has also a certain meaning given by its level of absolute or relative truth in the situation, in which it is communicated. All this is not the kind of contextualization intended here. Finally, the sense and the intension of a statement within a speech or a text is also shaped and narrowed down by other statements told or written previously in that speech or text. And this latter apprehensive work is the "role model" for this tool.

When human understanding tries to tackle complexity and to turn it into sense, then it is not trying to exhaust the whole object in one gigantic statement. Its preferred and intuitive method is the narrative flow, which is a set of coherently and loosely connected statements, the connecting story line being a succession of knowledge gaining experiences.

The result set of an SQL query, as it is retrieved within the DBMS, is totally agnostic to the execution history of other SQL queries. With standard SQL you can put a result set in a contextual relation with the result sets from another statement, only by creating a new SQL query, which includes all of these SQL queries, constraining the user to grow up a bigger, less flexible and harder to understand SQL statement.

The purpose of this tool is to give the user the possibility, the formal means to "contextualize" the result of an SQL query without the need to modify any of the participating SQL queries or to create a new query.

Next Page->