Laserfiche WebLink
prototype rather than assuming that the machine is powerful enough to overcome every performance- <br />drain that occurs. <br />Real-Time Database Access <br />Data storage schemes will be adjusted over time to account for the increasing size of the database <br />and the query patterns used to access the database. For example, data tables may be indexed such <br />that often-queried records are at the top of the table; consequently, a query will not have to search the <br />entire table to find the record. <br />The primary method of accessing the database will be through the use of low-level ESQL queries <br />from application programs such as DMI utilities (see Task Memorandum 1.05-7). Access of this <br />type can be termed "real-time" because applications that are accessing the data are truly accessing <br />the master data in the CRDSS database. Specific data types (e.g., "LatitudeLongitude") will be <br />queried using SQL statements specifically developed for the CRDSS database. Utility routines that <br />access compound data (e.g., "StationPhysicalData") may have to perform several SQL queries in <br />order to get all of the data for the compound data type. These utility routines will be optimized by <br />determining the fastest method for retrieving the compound data, even if it means retrieving extra <br />information and then ignoring some of that information (i.e., get one big piece from the database <br />rather than getting several smaller pieces and then putting them together). This is a performance <br />issue because each query to the database requires the database engine to search an index to find the <br />appropriate record. <br />Another issue is that of multiple queries for the same data type. For example, if the physical <br />characteristics of ten gaging stations are to be queried, then it may be more efficient to grab multiple <br />records from the database in one query rather than to make ten separate queries. In terms of coding, <br />a routine may be written that retrieves multiple stations using the best method rather than using a <br />loop to call a single retrieval routine. This issue will be studied as the system takes form and <br />performance can be evaluated. <br />Remote access to the database may be the most critical database access issue. Because the database <br />will reside on a single database server, all other workstations running applications that query the <br />database will depend on network communications for data transfer. A slow network or a large data <br />transfer will inevitably impact the performance of the system. One purpose for the briefing room is <br />to identify performance issues associated with accessing the database over the network and to <br />formulate alternative environments for running the CRDSS. <br />DMI Utility Performance <br />The low-level DMI library routines are described in Task Memorandum 1.05-8. The performance of <br />these routines is related to the issues described in the previous section. <br />High-level DMI utilities, as described in Task Memorandum 1.05-9, are programs that transfer data <br />from the database to flat files used by models. Because this procedure will entail reading data from <br />the CRDSS database, many of the issues described in the previous section affect the performance of <br />DMI utilities. <br />Because DMI utility performance will be affected by many issues, several alternatives for executing <br />DMI utilities will be considered. These alternatives may affect the procedure that users perform to <br />2 <br />A275 05.10.94 1.05-14 Malers, Brazil <br />