Previous | Table of Contents | Next |
Almost any task can be automated. There are several factors that come into play when deciding whether a task should be performed with a script:
Lets consider several tasks and determine whether or not the task should be scripted.
Daily Conversion Of Data From A Legacy System
Every day a set of data must be loaded from the universitys mainframe system. Some special applications have been developed on the mainframe, and IS (thats you) hasnt had time to implement those special applications on the new system. Consider these points:
Given these conditions, this task should definitely be scripted.
Preparing Summary Data For Daily Transactions
Every day at 4:30 P.M., IS must prepare a report for the University Accounting Office that summarizes the universitys transactions for the day.
Given these conditions, the task should be automated.
Pattern Analysis Of Stock Trends
The Vice President of Finance wants to see a report of trends in the universitys investments. The stock prices are keyed into the database by his secretary every morning, but the standard report doesnt help him predict where the investments are going.
Unless youve created a reliable method for predicting where stock prices are going and can translate that method into simple logical steps, youre unlikely to have any success using a script to generate a usable report. (And lets face it, if you had created a reliable method of predicting where stock prices are going, you probably wouldnt be working for a living.)
Scripts play a large role in most systems. If a script performs a task within your system, the script should be documented. A script to restore your database isnt any good if no one has any idea how to run it. The best place to document scripts is within the scripts header (or prologue), as illustrated in Listing 3.7.
Listing 3.7 A documented header for a script.
-- ***************************************************************** -- This script performs an analysis report of trends in student -- grades, broken down by professor. The report should help indicate -- if specific professors are showing unusual trends in grades. -- -- The script accepts the following parameters: -- -- 1) The first parameter specifies a department for which the -- script should be run. -- 2) The second parameter specifies what level of students should -- be examined. The values for this parameter are: -- -- 1 -- calculate grades for all undergraduates -- 2 -- calculate grades for all Masters candidates -- 3 -- calculate grades for all doctoral candidates -- -- The script is run from the Unix prompt by issuing the following -- command: -- -- sqlplus @grade_trends.report PSYCHOLOGY 2 -- -- -- The script uses these variables: -- -- 1) &&MeanGrade -- indicates the mean grade for all students -- in the program. -- -- There are no expected errors that occur when running this script. -- -- The script requires SELECT privileges on the STUDENTS, -- DEPARTMENTS, and ENROLLED_COURSES tables. -- *****************************************************************
The header shown in Listing 3.7 documents several important aspects of the script:
Scripts for your system should be in version control with the rest of the code; no one wants to have to re-create the backup script for your database or the report that took a week to write and debug. Its especially critical that test scripts (and their results) be stored in version control, because, at some point, the tests will need to be executed again.
Previous | Table of Contents | Next |