Gilles writes:
> 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.

I disagree...that's like saying "write C using only 16-bit ints".

When a language, or a database system, provides a suite of types/tools/whatever,
you always do well to consider using them.  On some projects, there may
be good reasons to restrict yourself to a subset.  On other projects,
there may be good reasons to use every last feature.

For databases, I ask two questions, with the first being more important
(usually):

   Is the data stored in a field used primarily for display to humans,
   or primarily for calculation?

   Is storage size important?

Let's look at a field holding a "to-be-shipped" date.

Dates often need to be displayed, compared, and calculated.  If the
predominant use of my date is calculation, I'll use some numeric
representation like days-since-1900 (but probably not MJD, Wirt :).
I can always convert it to YYYY-MM-DD for human display.

OTOH, if the predominant use is for display, I'll store it as YYYYMMDD.
I can always convert it for calculations.

(In some cases, for dates that don't change once entered, I may
store it in *both* forms and thereby eliminate *all* conversions,
at the cost of extra space!)

Now, if I choose YYYYMMDD ... should that be an I2 or an X8?

An X8 uses more space, but is human readable in a raw dump of the data,
(ASCII/hex dump) *and* uses less CPU to display.  An I4 is more compact,
and a bit easier to use in some languages for simple compares as well as display.

I.e., no clear winner...until you answer the two guideline questions!

> >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.

OTOH, you can also argue that there's a valid reason for using X for
numerics where you wish to overload the information.  For example,
if you have an age field, which you use 99% of the time in calculations
of various kinds (maybe you're writing software for an insurance company).
However, you want to be able to indicate that a particular instance is "unknown".
You could say, use I2 ... and special case that -1 means unknown.  Or,
you could use X4, with most values like "0030" (or whatever), and have
carefully defined (and controlled) special case codes like "NONE" or "????".
Why?  It's real hard to accidentally interpret "NONE" as a number in a properly
written program.  It's easier to interpret -1 as a number, however ...
because, well, because it *is* a number.

(The two reasons for overloading, as opposed to having a separate field for the
extra information (e.g., AGE-UNKNOWN) should be obvious: storage space and
program strength (with overloading, the "flag" and data never become
separated).)

The best example I've seen of the above concept is expiration dates.  Let's
use YYYYMMDD date representation, and add the concepts of "never", "expired",
and "unknown".  Even though this type should be classified as numeric by
Gille's proposal (it's used in arithmetic expressions), I find it easier
to store it as X8, with "NEVER   ", "EXPIRED ", and "UNKNOWN " as three
special values ... rather than using three numeric special cases instead.

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html