Re: it's not just the box dummy - it's just ahouseofcards.-Reply -Reply -Reply -- MIDRANGE-L

David 

Sorry to take so long to come back to you.  I am on holiday at present in
France but when allowed to by my family (!) have been creating a large
document with several gifs about Neural database concepts (part 1) which I
hoped would answer some of the questions that you and several others asked.
 Forgetting the size limitations, I tried to post it to the list, of course
without success.  There will be a second part in due course - I hope that
the two parts together will answer all questions to date and raise some
more.

Inheritance is an natural property of the NDB.  It does not work in the way
to which you are accustomed, and cannot be explained in a few words.  The
two documents should help you to understand, but not completely, you would
have to try it .  Inheritance of all attributes at lower levels is not
mandatory and not always appropriate and you can set it how you like.  All
attributes that are relationships can generally be accessed from either
direction so it easily copes with "where used" problems, etc., even though
no AS/400 logicals are used.  

The key field length of the NDB never changes, however many levels you go
down.  In my implementation, it can handle 1 billion entities for each
entity type and there may be 1 billion levels of hierarchical attributes
(i.e. lower levels dependent on higher level values) and at each level
there may be, for each entity, up to 1 billion attribute iterations - 
for instance - 

An entity type may have 1 billion separately defined attributes - these may
be at the same level or in hierarchies as required.
A company may have 1 billion employees.
A person may have 1 billion telephone numbers 
1 billion customers may each order all of 1 billion products, each ordered
from each of the 1 billion suppliers.
A company may take 1 billion orders, each of 1 billion lines, each line
being delivered to a different address of the 1 billion addresses of the
customer
A document may have 1 billion paragraphs, each of 1 billion lines!
There can be 1 billion� levels in an hierarchy but you can access a record
at any level and find out to which hierarchies it belongs without having to
search any of the hierarchies.

and so on. 

No space is reserved in advance of data being entered - for instance, if a
contact has no telephone number of which you are aware, no space is taken
and no "null" values are stored, but, if the next day you find they have
many telephones, you can enter their numbers without any problem.  You can
limit attribute iteration numbers if you require.

Because the key field structure never changes, the key field length remains
fixed all the time ( in my implementation,  it is defined in DDS as one 28
byte field, broken down in the kernel programs of the NDB).

An application is just another entity type with its own set of entity types
and attributes for those.  You can define for each application which
attributes are available for each entity type in the application and what
functions (add, update, delete ,remove, etc.) can be performed for each.  A
user may be able to add data to a particular attribute in one application
yet have no add rights in another, etc..  Security can be at the field
level.

In the real world (for most of us where the numbers are generally a little
smaller), there is no overhead in space or performance even when the
numbers are very small.  Equally, because the NDB is intrinsically
scalable, performance does not visibly deteriorate when the database is
very large.

Looking at your post and what you describe, perhaps the major difference is
the simplicity of the NDB. 
If you would, or any one else, would  like me to send part 1 of the NDB
concepts document directly to you, please ask.  

Rob Dixon
Erros plc
----------
> From: David Morris <dmorris@plumcreek.com>
> To: MIDRANGE-L@midrange.com
> Subject: Re: it's not just the box dummy - it's just ahouseofcards.-Reply
-Reply -Reply
> Date: 28 July 1998 18:58
> 
> Rob,
> 
> Is a Neural database another way of defining inheritance?  We have
database based inheritance in some of our applications such as our field
definition file.  For example a report field can inherit from a database
field, from a prompt field, etc.  A database field inherits from the file,
the prompt field, the display attributes.  The key is the parent object,
parent type, and object.  One major drawback is that a small change at the
top can cause big problems at the end of the chain.  This is because
encapsulation has been violated.  Because we seldom change the high level
definitions it is not a major problem.  The other option would be to build
a fields definition from a set of component attributes.  This approach is
more flexible but would require more work in the application to tie the
information together.  It also means it more difficult to override an
attribute such as field length on a display.
> 
> 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 accomplished?
> 
> David Morris
> 

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