The concept of distinct UDTs is analogous to the typedef construct in the C and C++ programming languages. Unlike predefined SQL data types, however, which are only moderately strongly typed, distinct UDTs are strongly typed, which makes them ideal for enforcing domains. You cannot declare CHECK constraints on UDT columns, so the UDT-as-domain concept cannot be fully implemented.
For example, you might want to define euro and USDollar as two different distinct UDTs even though both are internally represented as DECIMAL numbers. If euro and USDollar are defined as separate distinct data types, they cannot be compared directly or used interchangeably. In this example, a euro value cannot be compared to, or stored in, a USDollar type column.
A distinct UDT shares its internal representation with a predefined data type (called its source type), but it is considered to be a separate and incompatible type for most operations. You cannot define a distinct UDT based on any of the Period data types. Distinct UDTs encapsulate their underlying predefined data type. Therefore, operations and behaviors associated with the underlying data type are not valid, and users of a distinct UDT are only able to interact with its encapsulated value by means of user- or system-defined transforms, orderings, and castings, and manipulations by means of instance methods.
You can drop any of the system-generated semantics for a UDT (see System-Generated Default Functionalities for Distinct UDTs) and replace them with your own definitions
Vantage supports the definition of instance methods for distinct UDTs, which is an extension to the ANSI SQL standard. For example, you can define an instance method named round() to use with a new distinct UDT.