Object accessibility

Users are likely to query the data of two extended types: row data types and opaque data types.

To decide which data type to use, consider how accessible the elements of each DataBlade® module object should be:
  • Use row data types for any object that is a container and whose elements users always want to access.
  • Use opaque data types for indivisible objects or for objects whose representation you want to hide from your users.

For example, say the users of the SimpleMap DataBlade module want to see and operate directly on the street number and name, country, and postal code. You might decide to provide the Address data type.

If you create Address as an opaque type, each member of the underlying C structure can store a different element of the address. However, this means you must also define accessor routines for each element.

If you create Address as a row type, your HCL OneDB™ database server automatically provides direct access to each of the fields, as follows: 
CREATE ROW TYPE Address
   (street_number real, street_name varchar(40),
    city varchar(100), country varchar(40),
    postal_code varchar(20));
This allows users to write queries like the following example: 
SELECT * FROM employees WHERE address.city = 'Vienna';

In contrast, because users seldom need to examine the individual points of a polygon, you can create the Polygon type as an opaque data type. An opaque data type provides an efficient representation that you can operate on easily with C code. The query language interface remains simple.

When you design data types, ask yourself the following questions:
  • Is the data type just a container for a collection of values that users can access directly? If so, use a row data type.
  • Is the type naturally indivisible, or do you want to hide its representation from users? If so, use an opaque data type.
  • How can you represent your data to make it easy to use in SQL and to make end-user queries simple?