0

I am fetching records from database in PHP and MySQL and showing it into the jqgrid.

Now i request 1 page which encompass 10 rows data in first request.

to achieve that i fire one query to get total number of records and then calculate totalpages which contains all total records.

and second query to fire limited records i.e. 1 to 10 and next time 11 to 20 and so on.

so the problem is every time i have to fire two queries one to fetch the total number of records and other to fetch limited rows for a grid.

is it possible to fire only one query to achieve above thing ?

to fetch record in a normal fashion the above scenario is fine but if i preform serch then i have to fire two queries one to fetch total number of rows that matches the criteria and other to fetch only limited rows that meets the criteria

Update

Well my limits to access rows is depends upon the total number of records so i dont see any option to fire only one query. Please look how my PHP code is counting limit

1) Fire the query to access total records

$selectMemberData = "SELECT * FROM tbl_member";
    //some db code  ... 
    // store the total records value
    $count = $dbMemberData->numRows; 



if( $count >0 ) {
    $total_pages = ceil($count/$limit);
} else {
    $total_pages = 0;
}

if ($page > $total_pages) $page=$total_pages;


$start = ( $limit * $page ) - $limit; // do not put $limit*($page - 1)

   //Fire another query to fetch limited records 

    $selectMember = "SELECT * FROM tbl_member   LIMIT "  .$start.", ". $limit;

so my concern is when i use autocomplete search at that moment it would be pretty expensive to fire the two queries. and the issue is i have dependent on total records to get start and end limit

Hunt
  • 8,215
  • 28
  • 116
  • 256
  • As you can see we've gotten into a debate about what exactly you were looking for with this question. It'd be great if you let us know in a comment so that we can improve our answers, or up-voted something or marked an answer as correct because I don't really want to be having this debate. – mrmryb Sep 21 '12 at 11:59

3 Answers3

1
select * 
from yourtable 
inner join 
(
select count(*) as count 
from yourtable
) as t2
limit 0,10

which will add on an extra colum of count to each row which will be the total amount of rows from the whole table, in one query.

sqlfiddle for an example

If you'd prefer not to use the join you can use a union:

select id,count(*) as data 
from yourtable
union all
select * 
from yourtable
limit 0, 10

but then you have to declare all the columns in the first select. You can write it like null as column_name for each of them except for the column that you want to hold your count if you want them to be null otherwise they'll just hold random data.

sqlfiddle

I'm assuming you're using a while loop on your data so you could use:

mysql_fetch_assoc($row);
$all_records_count = $row['data'];
while(mysql_fetch_assoc($row)){
...do something with results...}

to get the first row which will hold your count and then start looping through the results after.

mrmryb
  • 1,479
  • 1
  • 12
  • 18
  • basically there are still two queries in this. Try `explain` on this you will know – Shades88 Sep 20 '12 at 20:17
  • @Shades88 Two internal queries compared to your two external queries? Just depends on what the OP meant, but together we have both bases covered. If he wanted one php query being executed then this is the way to go. Up to the OP to decide what he prefers. – mrmryb Sep 20 '12 at 22:06
  • you are correct. But as far as the standard practice goes, programmer should call a stored proc instead of a query directly. And in your case, row count field is added in every record, which is totally unnecessary. Instead there can be a different result set containing just `row_count` field and a main result set containing just what one wants – Shades88 Sep 21 '12 at 06:08
  • @Shades88 Since when is it standard practice to use stored procs - evidence? Just search for the term on stackoverflow and you'll see how divided the community is about their use. Additionally this question is not tagged as `stored-procedures` and from the description it seems likely the OP is firing the queries on the php page and therefore not using stored procs. I understand what my query is doing, but the OP asked to be able to write ONE query to get both results, and my interpretation is that he meant one php query. As I said, if I'm wrong then we have both bases covered. – mrmryb Sep 21 '12 at 09:58
  • Do you imply that complex multi-join queries be fired from front end? Make the application code ugly with many lines of concatenated string of sql statements? Make multiple connections to database for different queries? There are obvious advantages of using SPs and may be that's why people prefer SPs. At least I myself have seen all developers putting backend logic in an SP then calling it from app code. Try this, it's an article on SO itself http://stackoverflow.com/questions/462978/when-should-you-use-stored-procedures – Shades88 Sep 21 '12 at 11:06
  • `Additionally this question is not tagged as stored-procedures`. It's not necessary that answer be bound to the names of tags OP has put in – Shades88 Sep 21 '12 at 11:10
  • @Shades88 Is that a reason to not use queries within code, because it will look ugly? Have you looked at my code, it's not exactly long. And do you understand what the word 'multi' means? There is one join in my code, not multiple. Again make `multiple` connections, how exactly would that be happening with my code when it is one query? Of course in some cases it is better to use stored-procedures, but my point is that it is not necessary as you so claim. The answer doesnt have to be bound to the tags but the tags imply what code the OP is using, and that would be not stored procs. – mrmryb Sep 21 '12 at 11:24
  • @Shades88 Did you even read that link you sent me, at no point is there a consensus that stored procs are the greatest thing ever. `Use stored procedures when you have functional computations that can't be done in declarative SQL and are best left in the database.` is that the case here? `There are alot of benefits to using stored procedures, but I think many of these concepts have become outdated.` & `So, as a general rule, avoid writing stored procedures; writing your code in a general programming environment is more desirable.` You really need to provide better evidence for your arguments. – mrmryb Sep 21 '12 at 11:24
  • @Shades88 [What are the pros and cons to keeping SQL in Stored Procs versus Code](http://stackoverflow.com/questions/15142/what-are-the-pros-and-cons-to-keeping-sql-in-stored-procs-versus-code) Maybe after you look at both sides of the argument then you can try to convince me that stored procs would be better in this case. This isn't a debate about stored procs, it is about answering the OPs question in the most suitable way. – mrmryb Sep 21 '12 at 11:28
  • Have to look at other answers in that same link before jumping to conclusion. Try googling stored proc vs embedded sql statements. And about your query. It's all great. The points I have mentioned are about keeping things easier when it comes to communicating with database. And it IS REALLY IMPORTANT to keep app code clean and neat. – Shades88 Sep 21 '12 at 11:39
  • your query is great and it is indeed a solution to OP's question, except that it's returning a column of row_counts unnecessarily for every record which he will have to avoid in his code when he tries to render table data from it. Two result set will do that job best. Check any tutorial on how pagination is done using sql queries you will come to know. It's been a healthy debate so far. I got to know many new things. Thanks – Shades88 Sep 21 '12 at 11:44
  • @Shades88 I'm not really sure who you're claiming is jumping to conclusions. You threw out a link to prove that your opinion was right and mine was wrong without any references to back you up, and now that I've read through it and shown that whilst you are not wrong which I never claimed, but that the link does not back you up, your whole tone has changed. I'm not going to start googling the topic so that I can try prove myself, I dismantled your argument attacking me, that's all I needed to do. The code will not be harder to navigate because of one or two extra lines for my query. – mrmryb Sep 21 '12 at 11:54
  • @Shades88 `The points I have mentioned are about keeping things easier when it comes to communicating with database.` How does my code make it more difficult to communicate with the database? [MySQL stored procedures use them or not to use them](http://stackoverflow.com/questions/6368985/mysql-stored-procedures-use-them-or-not-to-use-them) the first answer suggests it is more difficult to use stored procs, the one after suggests it is better practice but it has a learning curve. So if the OP is not using stored procs he would have to learn them just to please you. – mrmryb Sep 21 '12 at 11:54
  • @Shades88 It is not difficult to avoid the extra column if you know anything about php, and if the OP doesn't then I'd be happy to give him a few suggestions. I have also added another query to my answer that does not use joins if you'd prefer that and avoids the extra column (non)issue. The OP was not asking for a tutorial on pagination, he was asking how to do what he wanted in ONE query. – mrmryb Sep 21 '12 at 11:56
  • you never dismantled any of my arguments and my tone has never changed. I have never claimed that your query can lead to cluttered code/create inconsistencies in db comm. I was talking in general sense. It's only you who is trying to pitch each and every of my points on your solution. I have said a dozen times that your query is indeed a solution. I added my points to show how it's usually done also because OP's question is related to pagination. – Shades88 Sep 21 '12 at 12:10
  • And even when my comments and suggestions are not related to your query you keep saying that I am attacking your solution. Please view this as a healthy discussion not an all out war. Thanks, I would no longer comment on this as it's turning out to be the latter case – Shades88 Sep 21 '12 at 12:12
  • @Shades88 I have nothing against you so don't consider this a war, but when you make claims like `standard practice` is to use stored procs then you are implying my query isn't as good as a stored proc, which is indeed an attack on my query. That's why I then come back and ask why stored procs are so much better, to which you throw out a link, which I in turn show does not support you as you claimed it would. Your tone went from `There are obvious advantages of using SPs and may be that's why people prefer SPs` to `Try googling stored proc vs embedded sql statements` because you had no evidenc – mrmryb Sep 21 '12 at 12:19
  • @Shades88 You made generalizations about normal queries: `Make the application code ugly with many lines of concatenated string of sql statements? Make multiple connections to database for different queries?` so I wanted you to show how those apply to my query. Why bring up something that is not applicable to this situation? Like I said, this is not a debate about stored procs, it is about answering OP's question, and therefore discussing the answers, not some generalization that you came up with. I am happy for you to argue against my query, but not with generalizations. and with evidence. – mrmryb Sep 21 '12 at 12:20
  • @Shades88 for example, saying querying the table twice will be slower than your query is acceptable. But then I will say that at least I use one query in the php page compared to two of yours. Saying your query is better because stored procs are better than normal queries because usually normal queries make the code messy and create multiple connections to the db and therefore OP should use your answer is not acceptable because my query does neither of those. That is why I was bringing things back to my answer. Also even in a more general argument you provide no evidence besides aesthetics. – mrmryb Sep 21 '12 at 13:28
0

Check out SQL_CALC_FOUND_ROWS.

Alain Collins
  • 16,268
  • 2
  • 32
  • 55
0

not neccessarily you have to fire two queries. You can fire a single stored proc and get two result sets from it. First one containing limited records and the other one containing total records.

For this you can use MySql's found_rows() function to find out how many actual records in a query that returns limited results using LIMIT clause. Read more about it here http://dev.mysql.com/doc/refman/5.0/en/information-functions.html#function_found-rows.

E.g

SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name
WHERE id > 100 LIMIT 10;

then fire this

SELECT found_rows();
Shades88
  • 7,934
  • 22
  • 88
  • 130
  • in a way m firing two query isnt it ? second for `found_rows()` – Hunt Sep 20 '12 at 19:58
  • Can't help it. But, if you put this in one stored proc, you will have to make only one DB connection instead of two. Most expensive part in a program is connection to DB second is DB latency. So at least, you can cut down on that part. – Shades88 Sep 20 '12 at 20:04