Gilles writs:

> There is nothing in your rebuttal that contradicts or argues against my
> main premise: ie, that a database construct should use only X or I data
> item types.
>
> You have eloquently argued the merits and demerits of choosing one or the
> other of X or I, but nothing that counters the main point.

re-read it.

Point 1:

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

Put into different words, I'm saying: "Gilles is suggesting unconditionally
throwing away elements of IMAGE ... that ('unconditionally' doing anything)
is always a bad idea".

I used the date example to show one instance why an inflexible rule of any
type is bad.


Point 2:

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

In other words, I showed that Gilles inflexible rule of making it an I2
isn't the best choice ... if some of the counter arguments are more
important to you (e.g., human readability, computational cost for displaying).

Point 3:

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

In other words, I showed how a computation intensive "numeric" field
could be better implemented as X-type rather than Gille's rule of I-type.


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