Re: it's not just the box dummy - it's just a -- MIDRANGE-L

John,

Thanks for the explanation.   How do you define a database that allows such 
queries as "are there any dates on this invoice?".  Can a neural database help 
identify such abstract associations?  How do we weed out the unimportant 
associations?  In our case trying to keep all associations at all levels was 
possible but impractical.  Do we build an association when needed, and then 
keep it if warranted?  What about re-wiring associations?  If my invoice date 
has a due date associated with it, can I change the invoice date without 
affecting the due date, which may be associated with a discount date?  How do 
you recognize when to change the association and when to keep it?

Thanks,

David Morris

>>> John Hall <jhall@hillmgt.com> 07/28 1:54 PM >>>
David Morris wrote:
> 
> Rob,
> 
>
Is a Neural database another way of defining inheritance?  <snip> 
> 

> Because we define this inheritance in a linking file that stores direct 
>relations between all types of objects we can tie fields to applications, etc. 
> Our structure can only return direct relations.  I cannot say where is this 
>field used?  Just where the field/parent is used.  This has turned out to be a 
>drawback.  It sounds like you may have addressed this issue.  Initially I 
>tried to allow this, but the key structure became quite large and cumbersome.  
>Any ideas on how this can be accomplishe
> 

> David Morris
> 

A neural database needs to store information the way you do.  For
example a date.  We have many rules for what is a valid date and what
isn't.  We aren't concerned about field lengths or storage when we think
of a date.  We see 1/1/98, Jan 1 1998, January 1st 1998, 1998-01-01 as
the same date. Also we may have special representations of dates that we
know and agree upon (Y2K, Christmas 1998, etc) 
On top of that we all know about the leap year, 100 years not a leap,
400 is etc.
But at a more detailed level we also have the simple rules; 12 months,
ordinal values from 1 to 12 have corresponding Names & Abbreviations. 
The # of days each month has etc etc.

When we use dates in our everyday lives we do not process every one of
these rules only the ones that apply to the situation.  

When you look at inheritance you would use the "Master" Data Type to
Define DATE.
You might then use DATE on an invoice.  If you add a rule to DATE, for
example bulgaria uses Roman Numerals for its month,  it is still a Date
and the information on the Invoice hasn't changed at all.  This is
similar to the way your mind thinks.

Properly constructed a neural database allows you to add rules without
destroying existing data.  To most modern programming techniches 12
months is a rule but to your mind it is part of the data defining a
date.

In the same way that the Invoice "inherited" the date the customer would
"inherit" the invoice.  The customer would really only have one
information record which would contain all the information. 

Programmers strive to gather information and disburse it in this manner
so the next logical step is to also store it the same way. 

It is only a matter of time before databases evolve to this point.  


John Hall
Home Sales Co.


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---