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 _______________________________________________ patterns-discussion mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
