Re: Database I/O Modernization

[Gad Miron <gadmiron@xxxxxxxxx>]

Just wo(a)ndering

Doesn't all these calls affect performance ?

Gad


> from: "D*B" <dieter.bender@xxxxxxxxxxxx>
> subject: Re: Database I/O Modernization
>
> @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. If someone
> would
> provide a programm, generating such modules, this might be called open
> source.
> @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. This would be more
> handy to use too, replacing the RLA Opcodes in the current programms with
> very similar calls. (BTW this should be done by a generic programm,
> generating the needed code.
> @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:
> - changing the table layout of the underlaying 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
> - replacing the RLA in the I/O modules, where needed, would enable the
> possibility of instead triggers, giving new possibilities for database
> redesign steps.
> - replacing rla by sql, multiple of these I/O modules could share same
> logic
> (diffrent order only)
> - 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.
>
> This might be a starting point, but at the moment, it's only making a
> diffrence in programms 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.
>
> D*B