[Tfug] RDBMS reprise

[Bexley Hall]

Hi, Tim,

--- Tim Ottinger <tottinge at gmail.com> wrote:

> > 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  :< )
>   
> Great point.  I have had three, not counting the
> PDA phone.  I only use the media player, phone
> numbers, and the alarm feature.  They're just
> not really convenient.

Yes, but *why* (not)??  :<  The idea seems *perfect*;
keeping track of all this *cruft* that is just not
worth remembering (appointments, phone numbers,
addresses, etc.) -- yet is "inconvenient" to
*forget*!

I've tried playing with several and find that I
have to force myself to carry it -- and only at
certain times (e.g., while I do my daily walk I
carry one to log my time exercising and busy my
mind -- Soduko -- while walking).  I.e. I am
not *compelled* to carry it.

I.e., it is "entertainment" for me just like
the mp3 is for you.

(By contrast, folks won't leave home without
their cell phone!)

> > So, for example, how do I safeguard against the
> > application crashing and leaving that "results"
> table
> > sitting on the server (indefinitely)?  
> I can't remember which do what, but some
> databases use the 'create temp table' and
> destroy them when the session ends.  Some,
> sadly, do not.  I have seen some that never
> collect and delete them, only keep them with
> limited visibility to the user.  That would be
> very very bad for you.

Exactly.  As would be any implementation that
failed to terminate a session if the connection
broke, etc.  (I assume using keep-alives to
show the connection/session was still active).
 
> However, most systems keep stats and you
> could query metadata for temp tables of a
> given age, assuming that they're no longer
> valuable.  Again, metadata is structured
> differently by different vendors.  I suppose
> you could make a timestamp wart in the name.
> I've not tried it.

Yes, but this clutters up the application with
details of the RDBMS's implementation (bad
design philosophy, IMO).
 
> > Are there ways
> > to explicitly/implicitly free up portions of that
> > table as my application determines that it is
> finished
> > examining them?  
> Temp tables can be dropped, or you can
> "delete from/where"  But sometimes you will

Ah!  ^^^^ good point.  Though it would be nicer if
the DBMS could just "walk behind me" (i.e. one step
behind my cursor) deleting anything it wanted to
reclaim...

> have to clean the db to get space reclaimed.
 
> > 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)?
> >   
> If you drop them or if the db cleans up temp
> tables on session end.   Especially if you hold
> open a transaction.
> > Just *how* clever are the RDBMS implementers? 
> I.e. do
> > they exploit technologies like CoW to minimize the
> > impact of this type of usage
> During a transaction, a lot of them use mvcc,
> which is pretty amazingly useful.
> 
> > (sigh)  I think I'll go back to crimping CAT5
> cables!
> > At least, there, I can *see* my problems!  
> And I don't argue about the questions. :-)

(sigh)  Ah, well... that's what makes it
*interesting* -- and keeps work "fun"!  ;-)

Thanks!
--don


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ