Re: A nongeneric bounded string array type (in database code)

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Robert I. Eachus wrote:
> Warren W. Gay VE3WWG wrote:
>> I mean, is the program going to say "select the oldest person,
>> because the younger person is less likely to need drugs?"
>> I doubt it ;-) Even if you have such a process, then you
>> would use a ORDER BY clause, and accept the first row.
> 
> The (personal) phone book example is a good one to explain this.  If I 
> really want to display all matches as long as all is less than say 20, 
> the code for doing so is much simpler.  I ask for the first 20 matches, 
> and if I get less than 20 I display them and I am done.  If I get twenty 
> matches returned now I get the total count and do all the paging cruft. 
>  It keeps the normal case fast, simple and easy for the user to use, 
> while allowing for extreme cases.

But you don't need an array to do this.

...
>> Your package doesn't allow the programmer to make that
>> distinction, which, for me is a show stopper.
> 
> Actually, I have a trick I use for that.  There are four values in the 
> Ada definition of Latin-1 that are not only control characters, but have 
> no defined meaning in ISO 6429.  (Reserved_128, Reserved_129, 
> Reserved_132, and Reserved_153.) I often use these in database text 

Major yuk.. bending all the rules to push an implementation.

> fields as markers for special types of data.  For example, I'll use a 
> null middle name string to indicate a value not supplied, but 
> Reserved_128 as "NMN" (No middle name), and Reserved_129 followed by a 
> letter as "MIO" (Middle initial only).

And now, how do you code this in SQL, when you want to
to do an ad-hoc query for those cases? Man that is ugly!

> I figure using the type cuts my effort in writing programs 

OK, it is the "write the program efficiently" argument. You're
in league with Perl! ;-)

> that access a 
> database and display the results as HTML by about 25%.  I'll be the 
> first to say that it is possible that I could use some other method and 
> do it even faster,

The lowest price is not always the law ;-)

> but right now coding and debugging the queries is a 
> small part of the effort.  

Right, so why not stick to more ideal abstractions, then looking
for ways to bend the rules?

> In fact the big improvement from using the 
> new type is that the code is all independent of field sizes, including 
> the Ada declarations.  (Of course I still have to set some sizes in the 
> data dictionary.)

Well, the null handling definitely is lacking. No type strength,
and all numerics must be marshalled into and out of strings, with
of course, no type checking either. Ad-hoc queries must adopt the
strangest of null conventions; certainly non-standard ones!

Sorry, but I cannot agree that this is good or "better".  But then,
its your code, and you're free to express yourself in that code,
as you please... just as the Perl programmers are ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg