Page History

...

The last two points need some elaboration:

EIS (Executive Information Systems)

Everybody has seen the demonstration. The executive clicks on an icon and 2 seconds later a pan-dimensional chart of product sales, grouped by category, is shown, year to date, for the last 25 years. The graph is then used at the next board meeting and the executive receives much acclaim.

...

• EIS systems need to be planned and carefully designed.
• EIS means summaries.
• Summaries mean reading lots of rows of data.
• Reading lots of rows takes time and consumes a lot of CPU power.
• Most useful and rapid EIS systems keep "pre-summarized" data.
• The end users actually query the summary data.
• The summary data may be updated dynamically or cyclically.
• Designing and maintaining summary data means extra design and programming effort independent of any generic tool being used.

Data throughput

This is really an extension of the previous point.

...

• Many of the old DP rules about benchmarking and load testing, etc. seem to have been lost in the scramble for client/server applications.
• The old rules still do apply. If you ignore them until your application is complete then you are taking a large risk.
• Building client/server applications and using client/server tools may place a great deal more load on your LAN and twinax communication subsystems. Can they handle this increased load?

To Summarize:

• Spend a lot of time in design
• Use virtual fields to do dynamic "joins"
• Use triggers
• Put validation rules into the Repository and I/O Modules
• Distribute load/logic across the Client and Server
• Avoid pushing too much data through communication subsystems
• Do realistic tests/benchmarks before implementation
• Note that the amount of data transferred includes not just data from the database on the Server to the Client program but also from the Client program to the UIM (User Interface Manager).

This is very important and often overlooked.