Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!bloom-beacon!eru!luth!sunic!kps!peno
From: peno@kps.UUCP (Pekka Nousiainen /DP)
Newsgroups: comp.databases
Subject: Re: RDBMS sux
Message-ID: <626@kps.UUCP>
Date: 12 Nov 89 02:49:31 GMT
References: <860@anasaz.UUCP> <CIMSHOP!DAVIDM.89Nov7102914@uunet.UU.NET> <881@a <29421@iuvax.cs.indiana.edu>
Reply-To: peno@kps.UUCP (Pekka Nousiainen /DP)
Organization: Kuwait Petroleum Sweden, Stockholm
Lines: 17

In article <29421@iuvax.cs.indiana.edu> kitchel@iuvax.cs.indiana.edu (Sid Kitchel) writes:
>	On the implementation front, it is clear that array operations as 
>opposed to one-at-time cursors could be useful to the application writer.
>In fact ORACLE agrees so much with this view that they have provided array-
>oriented insert and retrieval in their embedded SQL facility.

Using arrays speeds up "batch" operations significantly (factor of 5) but
in my experience arrays are of no help to the application programmer.  The
situation is similar to reads and writes in C language.  Reading and writing
one character at a time is most convenient, but very expensive if one uses
the read() and write() system calls.  Hence C has a buffered interface to
read and write - <stdio>.  The problem with Oracle arrays is that there is
no analogue of <stdio>.  Each instance must handle the buffering details.
While they are not much, they do amount to something if one has tens or
hundreds of programs to maintain.
--
peno@kps.se