HP3000-L Archives

June 2002, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Wayne R. Boyer" <[log in to unmask]>
Reply To:
Date:
Wed, 26 Jun 2002 16:12:14 EDT
Content-Type:
text/plain
Parts/Attachments:
text/plain (34 lines)
In a message dated 6/26/02 5:27:58 AM Pacific Daylight Time,
[log in to unmask] writes:


> Anyway, my question is this:  Does it make more sense to store this data in
> an Image data base where it is more "protected" (my impression only, is it
> really?) rather than in a "flat" file, which, by implication, is less
> well-protected?
>
>
>

My philosphy is to always store ALL DATA in the DATAbase.  Sometimes this
isn't completely practical.  Long term, this will reduce the amount of future
code changes and allow for smarter software.  I've seen lots of 'static' data
get very volatile as business situations change.

If for some reason, a file/database is currently impractical to implement,
don't hardcode any values in each source code file, at a minimum, park the
data values in a COPYLIB member that is part of WORKING STORAGE.  That way if
a value changes, you only have to change the one COPYLIB location and
recompile.  No individual code changes.

The coding effort comparison between a flat file and an extra Image dataset
might result in less effort to go the Image route.  Reason being, you
probably already have chunks of code written to do most of the overhead work
(DBOPEN, DBCLOSE, etc).  All that you might need to add is a single DBGET on
the new dataset.

Wayne Boyer

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2