Re: An object-oriented network DBMS from relational DBMS point of view

On Mar 15, 9:21 am, "Roy Hann" <specia..._at_processed.almost.meat> wrote:
> "Lee Fesperman" <first..._at_ix.netcom.com> wrote in message
>
> news:1173943006.814718.209080_at_n59g2000hsh.googlegroups.com...
>
> > On Mar 14, 3:59 am, "Walt" <wami..._at_verizon.net> wrote:
> > Besides, 'programmer productivity' is not high on the list of goals
> > for database management systems, though I would say that RM has made
> > significant contributions to productivity over the years.
>
> I take it the term "productivity" here means something like "lines of code
> required to solve a business problem"?
>
> It is my unshakable opinion that RM has the potential to very nearly
> eliminate the need for programming as most people would understand the term.
> But programmers, through sheer numerical superiority, are unstoppable
> code-generators. They have ensured that RM (or rather, RM-inspired)
> products have had very little impact how much code is written to solve a
> problem. I started out in the late 1970s writing applications that
> navigated the databases of the day using quite simple APIs. Most of the
> code I look at today substitutes handfuls of my old API calls with a similar
> number of EXEC SQL OPEN CURSOR and EXEC SQL FETCH statements. I would be
> hard pressed to swear there has been any increase in productivity at all.
>
> There has certainly been an increase in code proliferation, but that ain't
> my idea of productivity.
>
> Roy
I see what you mean. I do not quite believe that there is any productivity improvement in the past years. Quite the contrary. As far as db's are concerned, increase in productivity have still to be established even in a common sense perspective.

Procedural oriented implementations in SQL DBMS (cursors, fetch etc... ) on dbms's and the breaking of RM design rules (unormalized schemas) causes most system to generate an immense overhead that totally defeats the advantages of RM inspiration of SQL DBMS's: use of NULLS forces tons of *adjusting* short life term code such as adding numerous IS NULL/IS NOT NULL to make results correct, non independence between the logical and physical layers on direct image forces an ultra reactive response to performance (defined as response time) problems and therefore a constant mobilization of teams of DBA and developpers to make constant performance adjustments on systems. Besides, the fact is that most practitionners or developpers who code on SQL current DBMS's have no clue about the possibilities of set operations: as soon as the operation gets beyond the simple *select ...where...*, they tend to automatically get back to procedural approaches killing both performance and productivity (procedural code requires more lines to code even than good ol SQL)...

My two cents... Received on Thu Mar 15 2007 - 09:45:38 CET