Re: Design shift of view

Tim,

At some point it all comes down to an abstract representation.  I have heard 
that IBM does not intend to create a more object friendly database on the 
AS/400 due to a lack of customer demand.  I also do not know what a neural 
database is and where it may fit in.  Therefore, the debate from my 
perspective, is how close can we get using the tools at hand.  I have OS/400, 
DB2/400, DDS, panel groups, CL, RPGIV and SQL.  If we assume that less than 20% 
of our code directly supports the business rules and relations, we still have a 
lot of room for improvement.  We have gone from wires, to source based 
programs, to templates, to generators.  Next in line are components -- unless 
someone has a better idea?

David Morris

>>> Tim McCarthy <twmac@mindspring.com> 07/26 4:29 PM >>>
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.  


At 08:42 AM 7/25/98 -0700, you wrote:
>
>
>That was me.
>
>It's the storage of information I was referring to, not the presentation.
>
>You are correct in that this is the way the forms appear. (and always
will)  The
>question I rose was why should the underlying files look this way. I
correlated
>that we store disk data the same way we stored punched card data. Unit record
>processing.
>
>Although we can pick any length of record we want, we are still doing unit
record
>processing. Both logically within the program, and physically within the disk
>file.
>
>The question then became, how can we logically do what we have always
done, yet
>change the underlying physical constraints of a "record" in order to permit
>dynamic changes to a files structure while an application is in use.
>
>James W. Kilgore
>qappdsn@ibm.net 


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