[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