Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
> Marc Delisle schrieb:
>> Hi,
>> I am seeking your input about the following issue. Normally if a user
>> just browses a table, he can use the navigation << < > >> and
"Page
>> number" to move thru the table. LIMIT clause is generated accordingly.
>>
>> Now if a user typed a LIMIT clause, what should he expect?
> seeing what he queried, if he wrote LIMIT 0,2 we should show two lines per page
>
>
>> (1) To be able to move thru the entire table
>> (2) or just thru the result set he chose in his LIMIT clause?
> table = result !?
No sure I understand your question, but the result set from a query is
different than showing the plain table. See the other answer by Alexander.
> (1) with his limit as initial rows per page
>
>
I thought about this. We could use his "LIMIT x,y" to fill the "Show y
rows starting with record #x". But I'm still not sure: why did the user
put an explicit LIMIT? To limit the initial display, or because he's
really not interested in seeing other rows?
if he is not interested in seeing
other rows, pagination will not hurt?
It won't hurt, but I tend to respect his
explicit LIMIT for consistency.
the problem is, if we omit all rows not in his
LIMIT and do not display
pagination, and he re-sorts the result by clicking on column he will get
completely different rows, cause the sorting is not done on the result, but
on the on the source of the result before the LIMIT - i think this will
confuse even more, or?
Starting with 2.11.4, the sorting on column headers is done on the
results, respecting an explicit LIMIT.
having a query like:
SELECT * FROM `tab` ORDER BY `a` LIMIT 3
with more than 3 rows in `tab`
will result in 3 completely different rows when clicking on column `b` in
the result table
is this what the user expects?