[Info-vax] CRTL and RMS vs SSIO

[Arne Vajhøj]

On 10/14/2021 3:12 PM, Dave Froble wrote:
> On 10/14/2021 1:48 PM, Simon Clubley wrote:
>> On 2021-10-13, Dave Froble <davef at tsoft-inc.com> wrote:
>>> On 10/13/2021 7:23 PM, Arne Vajhøj wrote:
>>>> With a relational database in is one SQL statement.
>>>>
>>>> With an index-sequential file it is writing a conversion program.
>>>
>>> Not always.  With DAS that utility already exists.  And a bunch more
>>> utilities, that work with any DAS file.
>>>
>>> RMS isn't the only product around ...
>>
>> Can that utility be used while existing programs which don't need the
>> new field continue to run at the same time as you are adding the new
>> field ?
>>
>> If yes, is this still true if you are not allocating the new field
>> out of existing dead space in the record and need to extend the
>> underlying record to hold the new field ?
>>
>> IOW, is there any application downtime while you are adding the new
>> field in DAS ?
> 
> In a word, yes.
> 
> Now, tell me that a database doesn't defer some transactions if it is 
> re-defining a table definition.

I would expect an update to be waiting while conflicting updates
complete for both DML updates (data updates) and DDL updates (structure
updates) even though I think it is rare to do structure updates on
running system, because often a database structure changes require a
matching application update (not to make it continue to work, but to
activate some new feature supported by the new database structure).

> In the era that DAS and a whole bunch of software comes from, downtime 
> for maintenance, backups, and such was normal.
> 
> Today's software benefits from new capabilities, new requirements, and 
> such.  That is a good thing.
> 
> But consider where the new capabilities came from.  Perhaps learning 
> things while using older software?
> 
> Arne figured a new conversion program would be required.  Not with a 
> product that anticipated
> such conversions, and provided methods to perform them.  Does DAS have 
> limitations?  Damn right it does,
> and I seem to recall writing multiple times that if I was designing an 
> application today, I'd most likely
> choose a modern RDBMS.

RDBMS sure got some advantages.

Lots of functionality.

A few dozens of products to chose from - from bloody expensive to free.

Standard interface language SQL known by maybe 15 million developers
worldwide.

That makes a pretty good case.

But not necessarily for all cases.

A product like RocksDB was created just 9 years ago. And it
illustrates that there are cases where a RDBMS is not the best choice.

>                         However, I sometimes get the impression, perhaps 
> mistakenly, that some might feel
> that every year everything should be re-implemented using new 
> technology, throwing out all the old stuff.
> That sort of irritates me.  After all, it was the old stuff that got us 
> to where we are today, including
> the lessons that caused the development of newer methods.

Definitely not every year.

Major conversions are very expensive.

And there is a reason that "leading edge" is sometimes
spelled "bleeding edge".

And sometimes new technologies that looked promising turns
into a dead end.

But maybe a big technology lift every 10 years.

Arne