The target list

The target list is where simple computation occurs.

Consider providing DataBlade® module routines for common computations on opaque data types. You can perform the computation in the DataBlade module to eliminate the need to implement the routine in the client application. You can use DataBlade module routines in the target list to reduce the amount of data transferred from the server to the client and improve performance.

Consider the following sample query from the SimpleMap DataBlade module: 
CREATE TABLE cities (name text, population integer, 
   boundary Polygon);

Polygon is a data type supplied by the SimpleMap DataBlade module.

To retrieve a list of all cities, their populations, and population densities, you can submit the following query: 
SELECT name, population, population / Area(boundary) 
   AS density FROM cities;

In this example, the Area() routine is supplied by the SimpleMap DataBlade module. Area() returns a floating-point number that is the area of the supplied polygon. You can invoke the built-in division operator to compute density from population and area. This query does a simple computation in the target list by using a mixture of DataBlade module and built-in routines.

This computation can also be done on the client. However, the client must implement the Area() routine for polygons, and the server must ship all of the polygons to the client. This operation is more expensive than shipping the results of the division across the network because polygons can be large. Generally, any computation that appears in the target list can also be done by the client. Thus, place target-list routines in the DataBlade module server routines only if there is an advantage to be gained by doing so.

If there is no advantage to running the routine on the server, leave the routine out of the DataBlade module and allow the client application developers to implement it in the client. If the server routine provides any of the following advantages, include it in the DataBlade module:
  • It reduces the volume of data transferred to the client.
  • It simplifies application development by sharing code among clients more effectively.
  • It benefits from the parallelism and scalability enabled by your HCL Informix® database server.

A simple DataBlade module that integrates well with existing data types is always better than a complicated one with many predefined routines that cannot be used with built-in or other DataBlade module routines.

The division operator that appears in the query calls a division routine built into your HCL Informix database server. Built-in routines and DataBlade module routines can be combined in queries, as shown in the previous example by using division with Area(). Routines from different DataBlade modules can be mixed to provide additional services.

When you design a data model, consider using built-in types and types provided by other DataBlade modules. In the previous example, you might define a new data type, called AreaType, to represent the area of geographic objects. However, then you must implement all the math on AreaType values yourself. By using real numbers to represent areas, you can leverage existing math and computational support in the database server and allow users to mix SimpleMap DataBlade module routines with other routines.

You might define a routine that computes population density inside the SimpleMap DataBlade module. The routine takes two parameters-a polygon and an integer-and does the division itself. However, no real semantic power is derived from this design. Leave special-purpose routines out of the DataBlade module to keep the interface simple and to let developers define their own expressions or routines to compute specific values.