[Tfug] Still another RDBMS

[Bexley Hall]

--- Choprboy <choprboy at dakotacom.net> wrote:

> On Tuesday 06 November 2007 10:56, Bexley Hall
> wrote:
> [snip]
> > It is also foolish to do this since it would
> require
> > client-side code to "filter" the results -- i.e.,
> > "display entries 1 - 10", "display entries 11 -
> 20",
> > etc.  That's something the RDBMS is *optimized* to
> > do, already!  (e.g., "show me all the names that
> > begin with 'G'").
> 
> Not just sorting... SQL has a function to limit
> results returned as well, to 
> consistently show results 11-20:
> SELECT * FROM data WHERE x=y ORDER BY index LIMIT
> 10,10;
> 
> > I *think* cursors let me more efficiently access
> > the DB in this manner.  But, I have some concerns
> > about their implementation.
> >
> > - are they a server-side feature (vs.
> client-side)?
> >   I.e., that functionality could also be
> implemented
> >   on the client-side (but at a much higher cost).
> > - how do cursors address reader-writer conflicts?
> >   I.e. what if an entry is inserted *before*
> (above)
> >   the current cursor position?  (how will it ever
> >   appear??)
> 
> I have never used cursors, but as I understand it
> basically creates a 
> serer-side temporary table of results that can be
> walked via SQL queries. 

I'm not sure of that.  :<  (But, my understanding is
far from complete).  I thought it was intended to
give the *appearance* of that but without that
"guarantee".  I.e., that changes to not yet viewed
results would be *visible* once you moved the cursor
to those entries.

Something I read recently also mentioned that you
might see the results of one of your own updates in
the results "later".  (the example IIRC refered to a
cursor parsing a query of entries sorted by "weight"
and the update changes one results "weight" to a
larger value -- which then makes it appear AGAIN
later in the result set; "weight" being a column, of
course)

> There are no read-write conflicts (again, as I
> understand it), beyond the 
> basic SQL constraints, as cursors only traverses
> results, 
> inserts/updates/etc. are performed directly on the
> DB. I *think* if you do an 
> insert of data, or what updated data, and have that
> result immediately, you 
> have to do a new select. But again... I may be
> talking out my backside 
> here...

<frown>  I will have to look for a more definitive
reference.  Everything I have read glosses over
cursors and the *details* of their implementation.

> I would personally ask the question, why do you need
> the client app to do the 
> DB query directly? That requires the client to have
> a full understanding of 
> the DB schema. Why not instead have a server-side
> interface that returns the 
> subset of results as requested? PHP/Perl/etc. all
> have tools built-in to walk 
> and manipulate DB results returned.

That;s possible -- but requires every application to
reside server side, effectively.  I'm currently
treating the DB in a manner analagous to a file
server -- where applications process files *outside*
the "file server", etc.

(though this bears consideration...)


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com