× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: it's not just the box dummy - it's justahouseofcards.-Reply -Reply -Reply
  • From: "David Morris" <dmorris@xxxxxxxxxxxxx>
  • Date: Thu, 06 Aug 1998 17:05:38 -0600

Rob,

Thanks for the explanations.  I am still trying to digest the conceptual 
document that you posted a few days back.  It sounds as though a neural 
database might be a very good way to store application meta-data.  We 
continually change the way we define applications and data.  Even though we are 
pretty good at pushing those changes through, it takes much more time and our 
application information is never as flexible as I would like.  I am sure I will 
have more questions when I can fully understand what you have posted to date.

Thanks,

David Morris



>>> "Rob Dixon" <rob.dixon@erros.co.uk> 08/06 12:30 PM >>>
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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.