I don't thing UDTs are a way to go on IBM i. Native I/O cannot be used on a
table with these data types. When using SQL access it creates the need for
UDFs to be defined which have their own performance overhead.
As for EDTCDE and EDTWRD... I don't think there is an equivalent in SQL.
There are other restrictions as well, but overall I think they're minor;
unless you happen to be using those functions of course :)
One thing that I find database architects on IBM i often underestimate is
the power of check constraints to implement business rules and ensure data
integrity.
Hth, Elvis
Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com
-----Original Message-----
Subject: Re: SQL version of Field Reference file
Jon,
With the availability of user-defined types, I wonder if field-reference
files belong in new work. They look like a "good idea" to me, but I
have not yet used them. I would be glad to hear of user experience.
For example, how onerous is it in practice to decide what aggregate and
arithmetic operators (or whatever) for each type and to define them?
Fer shur, it's more code. And as valuable as type safety is, I cannot
remember that I have ever accidentally added a customer number to a
dollar amount.
<aside>
Is there a more modern way to provide the functionality given
by EDTCDE() or EDTWRD() on a field in a field-reference file?
</aside>
Cheers,
Terry.
midrange.com
