Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / General DB Topics / DB Theory / July 2008

Tip: Looking for answers? Try searching our database.

Limits

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
JOG - 25 Jul 2008 01:55 GMT
Does anyone else find LIMIT statements particularly irritating? I
mean, as far as I know it has no basis in relational algebra, and yet
I find myself using it constantly. (In Oracle 11g I am still forced to
use the hideous ROWNUM which is even more irritating, and yet there I
appear to be, row-numming away till the cows come home).

So my question to cdt. Can LIMIT type operations, given their apparant
utility, be framed in terms of relational algebra, and if so how
elegantly can this be done? Off the top of my head the first approach
I would take would be to order the relation concerned via a new
attribute and then slice the appropriate section required... but this
certainly doesn't seem very stylish. For example, given a relation:
cars {model, price} (where for purposes of example, both model and
price are candidate keys) I can equate:

mysql:
SELECT * FROM cars
ORDER BY price LIMIT 5,10

oracle:
SELECT * FROM (SELECT * FROM cars ORDER BY price)
WHERE ROWNUM>=5 AND ROWNUM<=10

generic (well if mysql did nesting anyhow):
SELECT R1.model, R1.price
FROM (
SELECT R1.model, R1.price, COUNT(1) position
FROM cars R1, cars R2
WHERE R1.price > R2.price
GROUP BY model
)
WHERE position>=5 and position<=10
ORDER BY position

Any raise on what I have above? What then happens if price isn't
unique and the ordering on x has two tuples with equivalent values for
x? Meh, LIMITS and ORDERS bug me. I am forced to use them a lot in
everyday apps and yet they seem to be very much SQL and not RM. Having
said that I'm not losing sleep over them. Its all relative ;) Regards,
J.
Bob Badour - 25 Jul 2008 02:15 GMT
> Does anyone else find LIMIT statements particularly irritating? I
> mean, as far as I know it has no basis in relational algebra, and yet
[quoted text clipped - 36 lines]
> said that I'm not losing sleep over them. Its all relative ;) Regards,
> J.

See "quota query" and "partition".
Roy Hann - 25 Jul 2008 10:19 GMT
> Does anyone else find LIMIT statements particularly irritating? I
> mean, as far as I know it has no basis in relational algebra, and yet
[quoted text clipped - 5 lines]
> utility, be framed in terms of relational algebra, and if so how
> elegantly can this be done?

The queries to do that kind of thing can be written, but they are
not very intuitive.  I present them when I am teaching an SQL course
because if you can understand how they work then you really understand
SQL grouping and aggregation well. Consider this query that is
notionally intended to find the three most expensive parts:

SELECT * FROM parts p1
WHERE (SELECT COUNT(DISTINCT p2.unit_cost)
      FROM parts p2
      WHERE p2.unit_cost > p1.unit_cost) < 3

First of all, having taught many hundreds of very bright graduates
working for the big consultancies, I can literally count on the fingers
of one hand the number who ever claimed to "get" how this works.

Second--and this is the important bit IMO--this quuery doesn't even do
what the question asks for, and the reason is that the question itself
is broken.  The question presumes there is just one set of three parts
that are the most expensive.  But clearly we could have gazillions of
parts with an identical price.  The query above returns them all,
thankfully.

The point is that LIMIT and FIRST and all those types of limiters allow
you to proceed in blissful ignorance that you are asking a stupid
question stupidly.

Roy
JOG - 25 Jul 2008 15:30 GMT
> > Does anyone else find LIMIT statements particularly irritating? I
> > mean, as far as I know it has no basis in relational algebra, and yet
[quoted text clipped - 16 lines]
>        FROM parts p2
>        WHERE p2.unit_cost > p1.unit_cost) < 3

Yes, that's effectively taking the same counting and grouping
approach, written in a more compact way (although here you just have
the top 3 and not a range, which would convlute the query
somewhat...).

However, what really jars me in your query though is its implict
casting of a (nested) relation into an integer as part of the WHERE
clause.

> First of all, having taught many hundreds of very bright graduates
> working for the big consultancies, I can literally count on the fingers
[quoted text clipped - 10 lines]
> you to proceed in blissful ignorance that you are asking a stupid
> question stupidly.

As it is with ORDER BY I guess, which is supposed to spit out a linear
ordering where only a partial ordering may exist.

Regards, Jim.

> Roy
Roy Hann - 25 Jul 2008 16:22 GMT
>> SELECT * FROM parts p1
>> WHERE (SELECT COUNT(DISTINCT p2.unit_cost)
[quoted text clipped - 5 lines]
> the top 3 and not a range, which would convlute the query
> somewhat...).

> However, what really jars me in your query though is its implict
> casting of a (nested) relation into an integer as part of the WHERE
> clause.

Scalar subqueries are considered perfectly respectable amongst SQL
enthusiasts, but I confess they do stick in my throat and I have to
master myself to stay in character when I am teaching this stuff.  

I am a whore.  I admit it.

Signature

Roy

Tegiri Nenashi - 25 Jul 2008 19:04 GMT
> As it is with ORDER BY I guess, which is supposed to spit out a linear
> ordering where only a partial ordering may exist.

Could you please be more specific? All SQL datatypes I know (well,
those that I'm using -- string, number, date) are total orders. What
partial ordered datatype do you have in mind?
JOG - 25 Jul 2008 22:58 GMT
> > As it is with ORDER BY I guess, which is supposed to spit out a linear
> > ordering where only a partial ordering may exist.
>
> Could you please be more specific? All SQL datatypes I know (well,
> those that I'm using -- string, number, date) are total orders. What
> partial ordered datatype do you have in mind?

the tuple itself. For instance if we have relation:
R := {w, x, y}

where the tuples are:
w := (a:1, b:1)
x := (a:2, b:2)
y := (a:3, b:2)

then "ordering by a" yields a total ordering over R:
{(w, x), (w,y), (x,y)}

but "ordering by b" gives the partial ordering:
{(w, x), (w,y)}

Regards, J.
Tegiri Nenashi - 26 Jul 2008 01:17 GMT
> For instance if we have relation:
> R := {w, x, y}
[quoted text clipped - 9 lines]
> but "ordering by b" gives the partial ordering:
> {(w, x), (w,y)}

OK. But who the recepient of the ORDER BY output? I assume it is some
sort of SQL client. Can it understand partial order?
JOG - 26 Jul 2008 01:58 GMT
> > For instance if we have relation:
> > R := {w, x, y}
[quoted text clipped - 12 lines]
> OK. But who the recepient of the ORDER BY output? I assume it is some
> sort of SQL client. Can it understand partial order?

No, of course not, because clients tend to allocate tuples into an an
array, and certainly don't store them as a set even logically.
However, this is somewhat of a digression, because I was concerned
with the theory - whether such concepts can be integrated into RA, and
if doing so offers any utility. Ordering seems important.
Bob Badour - 25 Jul 2008 17:10 GMT
>>Does anyone else find LIMIT statements particularly irritating? I
>>mean, as far as I know it has no basis in relational algebra, and yet
[quoted text clipped - 33 lines]
>
> Roy

It's actuall wrong for more reasons than that. If two competitors tie
for a gold medal, we don't give the next guy a silver mdeal.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.