Re: Database I/O Modernization

On Fri, Sep 8, 2017 at 11:35 PM, D*B <dieter.bender@xxxxxxxxxxxx> wrote:

@open source: the link points to an example, tied to a special file module
cusmstf. You would need an instance of this for every file.

That's right, you would need a separate instance of the service program for
every physical and logical file.

If someone would provide a program, generating such modules, this might be
called open source.

What if the plan were to make the generator proprietary and charge
customers for it?

@interface: having one entry point with an parameter Action is not best
practice of modularisation. Why not export insertCusmst, updateCusmst,
SetllCusmst... with only those parms, which are needed?

Okay, but wouldn't the choice of interface be simply a matter of style or
personal preference?

This would be more handy to use too, replacing the RLA Opcodes in the
current programs with very similar calls. (BTW this should be done by a
generic program, generating the needed code.

Okay.

@modernisation: such a programm could be a first step in the right
direction, it decouples business logic from database IO, but there are
follow ons needed:

I understand the point about decoupling.

- changing the table layout of the underlying table, the change has to be
made for the I/O module only. keeping the current version adding a new!!!
now recompile orgies of business layer.

With this interface, a change in the record format would require a
recompile of the I/O server, plus all programs that call it. Otherwise
invalid data could be and probably would be pushed into the record from
referenced program memory.

- replacing the RLA in the I/O modules, where needed, would enable the

possibility of instead triggers, giving new possibilities for database
redesign steps.

I'm not sure I follow. It appears that you may be referring to replacing
the RLA op codes with SQL?

- replacing rla by sql, multiple of these I/O modules could share same
logic (different order only).

Good point. This interface has a lot of repeated logic in every service
program instance - an aberration of the Don't Repeat Yourself principle.

- replacing rla by SQL, the modules could be enhanced by an exported
subprocedure setOrderByCusmst (BTW: I'm using this as exercise in one of my
workshops)
- replacing rla by SQL the setllCusmst could be enhanced by the
possibility to use non key values for setll
- replacing rla by SQL the module could be enhanced by an exported
procedure filterCusmst (setting a where clause)
@joining files: this should be done in most cases in the view layer anyway.

Good points.

This might be a starting point, but at the moment, it's only making a
difference in programs where I replace the RLA by calls to such an I/O
module. As long as the implementation of the module simply reflects one to
one the same RLA operations nothing has really changed.

I think you make a good point about nothing being changed from applications
that just embed I/O op codes in the calling program. The error monitoring
that occurs in the I/O server just percolates messages up one level in the
call stack, which is what the DBMS does anyway. That's redundant.

Thanks for your feedback.