Re: Performance question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Miles Thompson wrote:
At 12:02 PM 2/1/2006, Mathieu Dumoulin wrote:

This is more a "How would you do it" than a "How can i do it" question.

Didn't have time to try it, but i want to know how mysql_seek_row acts with large result sets.

For example im thinking of building a node tree application that can have dual direction links to nodes attached to different places.

I was wondering if i could actually have two result sets that query everything sorted by ID (Links and Nodes) then just seek the rows i need instead of dumping everything in php memory. When i mean large i mean really large, more than the standard possible 2 mbs of data allowed by most php servers.

That's where the "how you'd do it" comes into play. I think i'd just query my tables, loop them but keep only the line (to do a data_seek later on) and ID in some kind of an hash table or simply an array. This would make it relatively fast without taking too much memory.

This is my solution, how do you people see it without dumping everything to memory or by making recursive SQL calls (which will obviously slow everything down i'm pretty sure)

Mathieu Dumoulin
Programmer analyst in web solutions
mdumoulin@xxxxxxxxxxxxxxx


I don't get it - what are you trying to do? Why? What is being visualized in the tree structure?

Building trees is expensive, you're essentially duplicating the index of the database, and if you fetch the data it's in memory regardless of how you present it.

The mysql_data_seek needs the row number - but by then you're on the client side, if this is to respond to a link.

Maybe I just don't see it - or maybe you're confusing server side and client side.

Regards - Miles Thompson


I'll try to explain my post better since people dont seem to understand it. I'm trying to illustrate a node tree client side, everything is considered a node in a tree. Now these nodes can appear more than once since i allow a node to be linked to different elements (Not just one parent, i may need to refer to a node several times.

Considering that a node may be there twice or more, that the number of nodes to work with may be quite high, i dont want to start copying into a php memory structure everything from the database that i might need... Nor do i want to recursively call SQL queries getting childrens of every parent. (That would cost a lot to the database server)

So i was wondering what would be the best idea to actually implement this... "dilema" of keeping it fast and not using too much memory.

As i understand your reply Miles, the query im doing resides in the php memory even if i don't fetch the data? If you do confirm that i WILL have to resort to recursive SQL calls. :(

To finish my post i'd re-explain rapidly my vision of doing this, but obviously i may be mistaken, maybe i can't do this. Taking two sql queries, one for the nodes, one for the links between nodes, i'd first read the results sorted by id, and do a mapping table for each result. When i need to use some info, i'd map the id of this info to the mapping table and retrieve the row from the result residing in mysql memory. (Up to now, this seemed logical until Miles told me that results are kept in PHP memory.) If this is still a valid way of doing it great. What would be the impact on the sQL server. Would this be a good way? I'd like to know from other pros how they'd implement it.

Mathieu Dumoulin

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux