At 10:57 AM 98/12/29 EST, Wirt Atmar wrote:
...snip

>It is for precisely this reason that I keep an oversized, heavy wooden ruler
>in my desk drawer to whap anyone's knuckles who wants to represent any other
>form of information where the individual numeric positions have meaning --
>most especially dates -- as a number. Such items should always be represented
>as strings so that they are both parsible and wildcards may be readily used.
>
>But that parsibility is not true for a number. The phrase "2@" has no meaning
>-- and it should not be supported for any form of numeric representation.
This
>is not merely a philosophical matter, good for academic debates, but one of
>fundamental practicality and an important consideration for end-user ease of
>use.
>
>The basic rule is: "If a number (say, a four) in a specific numeric position
>(perhaps the fifth position) has meaning, such as division number, style, or
>color, then the dataitem, even if every character is a number, must be
>represented as a string.
....

<<highly personal and perhaps controversal thoughts - on>>

I would like to take this one step further - by suggesting the following:

In the design of any TurboIMAGE data base (even non-IMAGE file constructs),
there should be only two possible data types defined: namely X and I.

Further, only if a data item is considered to be "truly numeric" should it
be defined as a I-type - otherwise, use X. To determine whether or not a
data item is "truly numeric" or not, one needs only to apply a simple test:
Will the item ever be utilized or have the potential to be used in an
arithmetic expression. If yes, this item should be defiined as an I-type,
otherwise use X.

For example, an employee number, even though perhaps comprising all digits,
should be considered as an X-type field, since one does not normally add
two employee numbers together. (I don't consider the employment of
check-digit validation processing upon an item as qualification for numeric
designation).

If this design philosophy is applied, it is immensly logical, and also
prevents all kinds of problems with other kinds of data items. For example,
packed fields are not only language-specific (COBOL, RPG) they suffer all
kinds of problems when dealing with implied signs (or lack thereof) in ODBC
interfaces.

In general, data types other than X or I, are impractical and illogical.

Yes - no Z, no P, no U, no K, no J, and with rare exceptions no R. If I've
omitted any, they are excluded as well.

Exceptions can be made in some very specific - though rare - cases, such as
the use of Real Numbers where necessary for the appropriate magnitudes
involved.

<< end of controversy >>

Thoughts and discussions are welcomed.

---------------------------------------------------------------------------
Gilles Schipper
GSA Inc.
HP3000 & HP9000 System Administration Specialists
300 John Street, Box 87651   Thornhill, ON Canada L3T 7R4
Voice: 905.889.3000     Fax: 905.889.3001
Internet:  [log in to unmask]
---------------------------------------------------------------------------