Re: DDS Support

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