[Tfug] Still another RDBMS

[Choprboy]

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. 
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...

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.

Adrian