Re: Design shift of view

I have been off-line for several days, driving through France, and am now
slowly catching up with my e-mail.  It is interesting how many posts the
"Design shift of view" thread, started by James Kilgore, has acquired in
the meantime.  

There are many good points that I could pick up on, but if I am only to
choose one, it would be that from John Hall dated 23 July.  I quote -

> To my view all you really need is one "data type."  This data type would
> then describe all other data types.  All rules essentially become data. 

This certainly ties in with my experience and implementation of the Neural
Database.  More importantly, it also, in my view, ties in with the human
brain.  All of us, particularly in the IT field, have some ability to
understand information of a type not understood by our parents, so I assume
that we did not inherit genetically this specific ability.  Instead I
assume that we inherited a more general ability which allows our brains to
cope with a great variety of "data types" by treating all data types as one
and the same - i.e. a "universal data type".  The tools that we have used
historically in the computer industry, have perhaps, because we do not
understand the mechanisms of the brain, made us differentiate between
"things" that are really the same.  Unless you believe that someone is
making separate decisions about every human brain for each new type of
information and deciding how and where in our brains each new type is to be
handled (i.e. reprogramming each individual brain separately), our brains
must treat all as the same.

I quote a very recent article in the British "Sunday Telegraph" by Stephen
Hawking - in the UK at least, the best known theoretical physicist, even
though most people who have heard of him, including me, are not sure what
theoretical physics is -

"Humanity is making great advances in science and technology, and the pace
of change is quickening.  I recently gave a lecture at the White House to
an audience that included the Clintons.  I argued that ..... progess will
continue at an ever-increasing rate.  In this situation, it is vital that
we all take part in the debate about where we are going.  We don't want the
knowledge and the decisions to be left to a few experts."

In our own small real-world ( I of course think it is very large and
important!), we have started our own, vital, debate.  When we have all
learnt all that we can, at this stage, learn, we will be as well equipped
as we ever will be to make decisions about the way our industry is to move
forward and so how we can best serve our users who are not necessarily
equipped to make such technical decisions.  If we are not to hold back
society (word-wide, not just our own local versions), we must make those
decisions fairly soon.  Making decisions means making judgements and taking
risk - putting our necks on the line.  But the worst decision of all, and
the most risky, is not to make one at all.   I do not believe that we can
stay as we are.


Rob Dixon
----------
> From: Tim McCarthy <twmac@mindspring.com>
> To: MIDRANGE-L@midrange.com
> Subject: Re: Design shift of view
> Date: 27 July 1998 16:10
> 
> James,
> 
> I heard the "radical" noises too. I understand the reluctance people may
> have in implementing "radical" solutions, what I don't understand is the
> unwillingness of some to consider them. You should hear the narrow minded
> debate on the EDI-L about a technology called BSI (which in my view has
> serious merit). 
> 
> I firmly believe that it will be internet driven commerce that will drag
> our database design into the next era because it's data sharing that best
> highlights the deficiencies with our current methods. You've only to look
> at the efforts involved in an EDI program to see this. As more companies
> are finally hitting the ROI wall with EDI they're beginning to explore
> alternatives (some early adopters anyway!). There's a lot of work being
> done by different standards bodies such as the 3WC with regard to
Business
> Object and DTD repositories. Initially what will happen is that people
will
> build bridges between current databases and the new repositories. When
the
> bridging work becomes too cumbersome and we begin to see the capabilities
> of the new technology you'll start to see change. I believe we're only
> about 3-4 years or so away but I can hear the sceptics laughing.
> 
> Tim 
> 
> At 09:16 AM 7/27/98 -0700, you wrote:
> >Tim,
> >
> >In a round about way I was bringing up the shackles we wear with file
> structures
> >emulating paper forms.
> >
> >As far as changing a record structure on the fly, I was hoping that the
> logical
> >conclusion would be to get away from the "record" concept altogether and
that
> >would bring us to the point of Rob Dixon's original post.
> >
> >There were some soundings about the acceptance of "radical" changes in
how
> we do
> >things.  IMO, radical can be brought to acceptance through logical
> conclusion and
> >the demonstaration that nothing gets lost and plenty gets gained.
> >
> >James W. Kilgore
> >qappdsn@ibm.net
> >
> >
> >
> >Tim McCarthy wrote:
> >
> >> James,
> >>
> >> It's interesting that a debate on DDS and display files turns to
database
> >> modelling. However I don't think the "design shift of view" has really
> >> shifted too far from our current modelling practices. Why should
"changing
> >> a record structure" on the fly be an issue. If we want a real design
shift
> >> we need to stop thinking in terms of files and record formats and more
in
> >> terms of the relationships that exist between individual data
components.
> >> And yes James you're right - the way we store information has to
change.
> >>
> >> We've based our database structure on the physical appearance of
business
> >> documents as they were printed on paper. Now that we've replicated
this
> >> "paper" document into an electronic form and stored it in our
database, we
> >> create a slew of programs to query this information in a 100 different
> >> ways. What we need to recognize is that a business document means
different
> >> things to different people in an organization - what the CFO and the
> >> assembly line supervisor need to see from a purchase order are two
> >> different things. The separation between business documents as
implemented
> >> in most databases tends to be reflected in most workflow processes.
Why do
> >> we separate "invoices" from "P.O's"? In reality it's just the
> >> "representation" of the same data that changes. The presentation of
> >> information (call it the GUI) on my screen should reflect my needs and
my
> >> role within an organization - it should not be a basis for how the
data is
> >> stored.
> >>
> >> Rob Dixon's earlier thread attempted to fire up a debate on the
subject of
> >> new database models. Given such an "encapsulated" business database we
> >> could focus on providing tools that would allow people to access
> >> information through more intuitive methods (such as function) than
having
> >> to specify fields in records in files. We could all be looking the
same set
> >> of data in entirely different ways - there would be no purpose or need
in
> >> having fixed screen presentations and the DDS debate would be moot.
> >>
> >
> >
> >
> >+---
> >| 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
> >+---
> >
> 
> +---
> | 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
> +---
+---
| 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
+---