Re: DDS Support

Nathan,

You points are well taken, but my discussion is limited in scope to a
database definition tool, not the database itself.

I'm a strong proponent of normalization, but IMHO, normalization, like
RPG, is a tool that has it's place and that place is -not- everywhere.

The use of a flat file was a deliberate design choice.  It's not that
hard to have one physical file, 18 bogus files in order to obtain an
externally defined data structure then do a CHAIN by file name with the
data structure named in the result field to map the fields.

If you want a real word example that may be closer to home, take a look
at the most common multi format flat file on your AS/400, your RPG
source.  I'm willing to bet that if you had to have your source in
multiple normalized PF's it wouldn't be pretty.

"Nathan M. Andelin" wrote:
> 
> Response to James W. Kilgore:
> 
> >Now I know, you're thinking how did you define records and fields in the
> >same file, not to mention files, programs, commands and what not and
> >have a normalized data base.  Simple answer: we didn't.  I know, shame
> >on us.
> 
> Any benefit of a non-normalized database?  Did it give you any more
> flexibility or extensibility?  Was it easier to design?  Was it easier to
> get data from or put data into?  More efficient?  Higher performance? Or did
> it result from a lack of planning - failure to see any future needs beyond
> the specific task at hand?
> 
> >There was an early discussion on the openerp400 mailing list that
> >pointed out that by having a service program perform all file I/O, you
> >would not need to define the file in the program, just the record
> >format.  It was promoted as "a good thing".
> 
> I don't agree that service programs should perform all file I/O.  Over time,
> the exported APIs get to complicated and inflexible.  I do agree that
> service programs are good for some file I/O.
> 
> >Now since I don't have to define the file, just the format of a record,
> >the old (multiple format files) can be resurrected by having a service
> >program that you pass FORMAT and KEY and it will pass back to
> >you DATA.
> 
> This may work fine for database maintenance, but what happens when you add
> inquiry, reporting, and business intelligence needs to the mix?
> 
> >The calling program does not need to know, nor need to care,
> >if the data came from a single file or multiple files.  And through
> >hiding the actual physical layer from the logical layer you can now
> >have multi format flat files and call it "modern". <VBG>
> 
> The problem with this "modern" solution is inefficiency.  The calling
> program (and users) wait while the service program wades through multiple
> record formats, "looking" for the correct data.  Works fine when the
> database is small.  Falls apart in large data stores.
> 
> >On the other hand you can define the 18 different formats as 18
> >different physical files and exponentially increase the difficulty of
> >the project and feel good about the amount of time spent doing it
> >"right", what ever that is.
> 
> Although a normalized database may require more thought and planning up
> front, it more than pays for itself in maintainability and flexibility in
> the long run.
> 
> >So, if you can write getCustomerNumber(definition), "how" is not really
> >important. Or is it?
> 
> It may be getCustomerNumber() today.  Tomorrow, someone wants:
> 
> getCustomerByCity()
> getCustomerByState()
> getCustomerByOrderStatus()
> getCustomerByProductCode()
> getCustomerAndOrder()
> getCustomerAndOrderAndItem()
> 
> and the needs never end.
>
+---
| 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
+---