General talk about software patterns

["Ralph Johnson" <johnson AT cs.uiuc.edu>]

The most important facts (to me) are that the total data is too big to
put in one place and you have all the source code and have plenty of
programming power.

There are two choices; you can either extract a summary of data from
each workstation and put that in a database, or you can have the
central reporting engine construct reports by communicating with each
workstation.  The first approach is centralized, the second is
distributed.  There are probably a variety of ways to do each.

I'll focus on the distributed approach, since I find it more amusing.

Start with the reports that you want to generate for the whole system.
 Are they all like the reports that you want to generate for a single
workstation?  If so, you might be able to generate the reports for a
single workstation in a machine readable fashion (XML would be best,
HTML or RTF would be OK) and then to merge them on the central
reporting engine.  The central reporting engine would create a report
by asking each of the workstations to generate a report and then it
would merge them to form the complete report.  The central reporting
engine wouldn't need a database at all.

This wouldn't be fast.  If you wanted to generate a report within a
second or two of a request then you'd need a different technique. 
Unless you can precompute them at the beginning of the day and just
display them on demand.

If your reports are X-Window programs written in C with embedded SQL
then this will not work, because there will be no intermediate data
structure that you can exprt and the final report is not something
that another program can use.  But if you are using a reporting
package that first queries the database and then runs the results of
that query though a translator that handles layout, you can export the
result of that query.

Anyway, this illustrates a point I've been making a lot lately, which
is that in modern software development, the design decisions we make
depend more on the current design of the software than anything else,
including customer requirements.  Requirements are obviously
important, but understanding the current design is even more
important.

-Ralph Johnson