looping the same loop?

vaska

i've wonked around for an answer to this with no luck...

i'm curious to know if it's possible (and how i guess) to loop the same results out multiple times...

for instance, i have a menu system that requires the exact same loop of data 4 times...and i'd like to do it all with one query...

can i? any advice on this?

thanks...v

olaf

hi,

This should be help:

for ($i = 1; $i <= 4; $i++) {
//here comes your existing loop
}

vaska

well, looping it four times consecutively would work, but that's not possible on this site...it wouldn't work...

???

thanks for the input...v

AstroTeg

Olaf's for() loop would work. In your reply, its not clear why you say it wouldn't other than you don't want your query being executed 4 times in the loop. If this is true, then you need to loop once to grab the record data and "cache" it. I use a template system and this would be a good time to have a template. You'd have this first loop fill out the template once. Then have a 2nd for() to run 4 times to output the template.

But its not clear if this is what you're looking for or not...

vaska

aha, yes...

thanks to both of you guys i can see how to do this now...the caching method is certainly what i was looking for but i wasn't aware how to start about doing this...i's git bizzy now...

thanks!

superwormy

Why do you need to cache it? Why not just use:
www.php.net/mysql_data_seek

AstroTeg

Why harass the database for the data when you can pick it all up the first time?

$string = '';
// the "caching" - basically load the data
while($row = mysql_fetch_array($result))
  $string .= 'Data: ' . $row[0] . "<br />\n";

// dump the string 4 times without hitting the DB
for($a = 0; $a < 4; $a++)
  echo $string;

superwormy

Why cache it in a string and waste memory / resources / cpu time when the result is already stored in internally in PHP, and accessible with www.php.net/mysql_data_seek WITHOUT HITTING THE DATABASE.

Once you run your query, PHP holds the result set internally until the PHP script ends. You're not hitting the database again unless you call mysql_query() again.

AstroTeg

True you're moving the result pointer from within the cached record set. Although your record set it using the same amount of memory as the record set I described above would be using.

The real difference is I believe the example I gave allows you to split off the database functionality with the actual code that does the display work. In doing so, you end up with more portable code, in particular the code that does the querying. You could take that function and use it else where and not worry about fiddling with the presentation mechanics (example: will it go to the browser or an email?)

Using the result set pointer, you'd end up with your display loop outside your record set loop if I understand this correctly (for an example, lets say there's 20 rows):

loop 4 times to print 4 times
- loop 20 times (1 once for each row - plus code to reset result pointer to beginning)

You have 4 * 20 or 80 iterations of the code block.

While the approach I described you will only have 20 + 4 or 24 iterations - of which the 4 will be very light weight assuming echoing is all you're doing.

superwormy

I'd have to look at what you said and all again... BUT... in any case, you're using twice as much memory.

You're using memory for the internally stored mysql result, plus memory for your string. Not to mention, if you store it in a string, you're stuck to that one format every time, not very flexible if you ask me.

But I guess it all really depends on the situation, I"d do it my way for the way I do things... but theres nothing saying that your way might not be better for the way you do things. Depends on what you like and what you're doing I guess.

AstroTeg

Originally posted by superwormy
You're using memory for the internally stored mysql result, plus memory for your string. Not to mention, if you store it in a string, you're stuck to that one format every time, not very flexible if you ask me.

No, the memory for the MySQL result could be released at any time - including directly after the while():

$string = '';
// the "caching" - basically load the data
while($row = mysql_fetch_array($result))
  $string .= 'Data: ' . $row[0] . "<br />\n";
mysql_close($link);  // close DB connection

// dump the string 4 times without hitting the DB
for($a = 0; $a < 4; $a++)
  echo $string;

Even if you have a large HTML string - lets say 26k. Multiply that by the number of rows (20 in the example above), you'd only have 520k of memory being used to hold the string. And you're only concatenating to the string so you're not stressing the hardware out.

But more realistically, I'd predict 1k or less would make up the string in one iteration. Multiply that by 20 and you have 20k at most. Even the most low-end equiped web server should be able to handle this without blinking.

Granted, you start pushing 1000 rows and a 64mb RAM web server is going to start choking. But at the same time, you would be feeding the client browser 26mb+ of data, which doesn't make a huge amount of sense (and in this case, an alternative approach should be used if it even comes up).

The basic idea here is to build build your basic output while you have the record set. If you want, ditch the record set and then loop just the output data as you see fit.

The additional feature to this is you do have the start of a template system...

superwormy

Boy, you sure are adamant on things, arn't you?

You'd actually need to use mysql_free_result() intead of mysql_close(), mysql_close() just closes the connection to the database, it doesn't release the results. :-)

But anyway, I'm trying to be a little open-minded here, theres never one best way to do something this general, it largely depends on the situation and how you program. If it were me, I'd actually store each result set in a multi-dimensional array so I could sort it and manipulate it later, but... thats just me.

AstroTeg

Originally posted by superwormy
You'd actually need to use mysql_free_result() intead of mysql_close(), mysql_close() just closes the connection to the database, it doesn't release the results. :-)

Ok, my bad. The goal is the memory is released directly after fiddling with it - if/when desired.

Originally posted by superwormy
If it were me, I'd actually store each result set in a multi-dimensional array so I could sort it and manipulate it later, but... thats just me.

I'd would think it would be a lot easier and better if the database engine handled the sorting. Yes, if you need to perform some manipulations, then this approach will not be a good fit. On average, I do not implement this concatenation trick unless something like what Vaska was mentioning comes up. Otherwise, I too just dump the results to the client when looping the record set.

But for this particular problem Vaska was having, I think concatenation would work fine for him. It should be an easy solution to implement with minimal code changes and minimum loop iterations.