• Subject: Re: Design shift of view
  • From: John Hall <jhall@xxxxxxxxxxx>
  • Date: Thu, 23 Jul 1998 12:46:28 -0400
  • Organization: Home Sales Co.

Buck Calabro wrote:
> On Wednesday, July 22, 1998 9:47 PM, James W. Kilgore
> [SMTP:qappdsn@ibm.net] wrote:
> >
> > > <<snip>>
> > >
> > > May I suggest that a broadened viewpoint is valuable in and of itself,
> > > and
> > > that a better class of solutions will come about *without* the
> > > absolute
> > > necessity of a radical change in philosophy.  All too often, people
> > > hear
> > > about a new paradigm, etc., and see such things as the "flavour of the
> > > month."  Rather than focus on the differences between existing design
> > > concepts and newer ones, perhaps we should focus on the similarities.
> > >  The
> > > sale would sure be easier...
> > >
> >

consider that all you are really talking about could be added into the
systems that we have now.  If you allow for the true use of a centrally
described database where all the "rules" are part of the definition and
each field is only described once, data storage details would be
irrelevant,  it would be very easy to derive the subset of information
which we currently use as externally described files to use with all
existing programs.  Create a logical if you will.  
Fortunately or unfortunately "backward Compatability" is always going to
be a key cost issue.  The only way to really get acceptance is to allow
the people in the trenches to work these features into existing systems
to show management (Bean counters) what the "new paradigm" really means.

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 approach is used in designing Object componets but not really used
to describe data.  Most of the building blocks of this type of system
already exists.  Some vendors have products which try to address this
but the key is to be able to store information and not to store data.

When we program we break information down into components and decide how
to store them.  If the balance of the components shifts in the future we
often must rewrite the entire system.

John Hall
| 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 thread ...


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

This mailing list archive is Copyright 1997-2020 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].