[Info-vax] wrong file format

Arne Vajhøj arne at vajhoej.dk
Thu Jan 7 20:24:29 EST 2021


On 1/7/2021 8:16 PM, Dave Froble wrote:
> On 1/7/2021 3:35 PM, 1tim.... at gmail.com wrote:
>> Don't disagree with what you are saying, but going to a database is a 
>> "rip and replace" option, vs incorporating some convenient features 
>> into legacy code.
>> If I'm supporting a large application with a large codebase, I'm not 
>> interested in ripping out the guts and making it use a relational 
>> database. I am, however, interested in making incremental improvements 
>> and simplifying code where possible.
>>
>> The ROI isn't there for most companies to replace the existing file 
>> system. The ROI is there to fold in incremental improvements in the 
>> course of doing enhancements and new development. The ability to do 
>> sets of data easily makes importing and exporting data to outside 
>> systems easier, or exposing data via web services easier. It's a lot 
>> easier to create a service that grabs a bunch of records in a single 
>> call than to have to loop and accumulate the data for the call. I 
>> suspect many of us have had to implement something like this. (Yes, 
>> solutions like Connex exist)
> 
> I had this exact situation.  I determined several things.
> 
> 1) The application just didn't have use, in current form, for such 
> enhancements.
> 
> 2) Any such project would extend itself to eternity, regardless of 
> original intentions.
> 
> 3) What use might a relational database be?

Easier development and easier management going forward.

But there is no free lunch. One has to pay for the conversion.

>                                             If for data mining and 
> such, the solution is simple.  Set up a RDBMS and the means to populate 
> and update it from live data files.  Which is what we did.  This also 
> keeps people out of the live data.

It is a lot easier to move data from one RDBMS to another RDBMS than
to move from some custom binary file to a RDBMS.

>> It's funny how years later, clever code usually turns out to not be.
> 
> I would not agree with that.  Perhaps resources today allow better 
> solutions, but, the old solutions still do what they always have done.

Clever code usually indicate more than just working code.

I get associations to "brilliant code" that by using every trick
in the book managed to shave off a few percent of CPU and memory
usage, but instead created a maintenance nightmare, because noone
besides the original author can understand the code.

Based on recent posts here then VMS itself does have a few of those.

Arne






More information about the Info-vax mailing list