Re: Design shift of view

Rob Dixon wrote:
> 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.

  I believe it was a certain Mr. Thomas Watson Sr who said, 'When you
come to a fork in the road you MUST choose one way or the other. If the
way you choose is wrong you will soon know and can reverse your course,
if it is right then you are on your way. To make no decision is to
fail.' (My recollection of his words)

  Maybe old Tom had something there!

  Larry Bolhuis
  Arbor Solutions, Inc
  lbolhui@ibm.bet


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