[Tfug] RDBMS reprise

[Bexley Hall]

Hi, Tim,

>>Bexley Hall wrote:
>> *You* (I, the programmer) know this is what
happened.
>> But, Joe User doesn't understand this.  Instead,
you
>> get a call to tech support (angry/confused
customer)
>> and you have to explain what *might* have happened.
>   
>Weinberg says: A problem is a difference between
things
>as perceived and things as desired. 

(sigh)  Unfortunately, this has turned into a
discussion
about the *application*/user instead of "using a
cursor"
in a RDBMS.  :<  Just "trust me" and assume that I've
got a good at system design.  <grin>  I spend a *lot*
of time studying problems before embarking on a
solution.

(To put things in perspective, I spent 500 hours just
*studying* tableting -- the manufacturing process, the
physics involved and regulatory agency aspects --
before
I prepared my design for that system)

One reason that I love using PDA's as examples is I
have
yet to come up with a good understanding of why *they*
are so poorly accepted (the *concept* sounds
wonderful;
yet I haven't met anyone who continues to use his/her
PDA after a few months with any regularity  :< )

Recall that I design *devices*, not "desktop software"
or "mainframe software", etc.  So, the types of users
I have to deal with are *not* "computer users" (even
if they happen to "use computers", when they interact
with my devices, they are "device users").  People's
expectations of computers and devices differ greatly!

(much to my chagrin :< )

--

I currently have several projects that rely
extensively
on an RDBMS for their design -- hence the reason this
is
such a key issue (i.e. one that I can't afford to "get
wrong").  I am planning on implementing the
server-side
cursor in the first of these to see just what other
issues
pop up before implementing it on more severely
constrained
devices.

I have ruled out the "little at a time" approach as it
requires far too much ad hoc coding to be able to
recover
from the various ways data can "change under you".  In
addition to "surprising" the user, the overhead for
the
various recovery strategies cost more (resources) than
it saves *and*, the added complexity of that code 
(decision points, etc.) detracts from the quality
(both
perceived and real) of the device.

Which returns me to the purpose of my original post:
looking for guidance in the sorts of issues that I
might face with a "server-side cursor" approach. 
I.e.,
*technical* issues related to how the RDBMS operates 
and how my use of that "feature"/mechanism might bite
me -- or other clients -- after the fact (e.g., it
obviously can tie up a lot of resources on the server)

So, for example, how do I safeguard against the
application crashing and leaving that "results" table
sitting on the server (indefinitely)?  Are there ways
to explicitly/implicitly free up portions of that
table as my application determines that it is finished
examining them?  Can the server do anything (other
than crash) that would make that table "go away"
unexpectedly (e.g., if database is vacuumed,
reindexed,
etc. in a scheduled routine maintenance task)?

Just *how* clever are the RDBMS implementers?  I.e. do
they exploit technologies like CoW to minimize the
impact of this type of usage (I can see how it could
benefit *me* but it may not be significant in larger
applications)?  I've learned not to underestimate
them;
they seem to be quite a clever bunch and I can benefit
from decades of work on solving these same problems
over
and over!  A *perfect* application domain for refining
algorithms since there is so much of the same sort of
*repetive* activity going on within the RDBMS  :>
I'd like to benefit from their experience second-hand.

(sigh)  I think I'll go back to crimping CAT5 cables!
At least, there, I can *see* my problems!  :>

Thx,
--don



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs