On Fri, August 18, 2006 1:32 pm, Adam Zey wrote: > I must say, I'm of the opinion that as much data processing should be > done in the database server possible. I agree with you 100% in principle... But in this case, we're talking about structuring the data in a PHP-specific data structure for easier application development. Last I checked, SQL has not yet Standardized on an Array datatype, much less all the major players actually IMPLEMENTED that Standard... If you didn't detect the dripping sarcasm laden in the preceding sentence, you haven't looked at SQL Standards versus actual implementation much... :-) > For one thing, munging data in > PHP > means you MUST have a complete copy of the result set in memory, > instead > of processing it row by row. No, no, no. We're just re-arranging the elements of the same result set from a 1-D array into a nested array! We're certainly not snarfing down the whole table and letting PHP sort it out! > PHP's 8MB memory limit can sometimes pose > a > problem if that munging involves several copies of the data floating > around. Yes -- But if you are loading in enough elements of a result set that the difference between the $result and the spliced $result matters, then you've got problems already. Also, the default 8M went up to 16M yesterday in 5.2.0RC2 and 6.0.* because you can't even [mumble mumble install PECL? mumble mumble] with 8M... At any rate, you're not quite envisioning the right thing here... > Further, database servers are, in my opinion, easier to distribute > than > web servers if load is an issue. While your single script could easily > connect properly to a database cluster, distributing the PHP scripts > involves somehow getting the client to the right one, either by > roundrobin DNS, or some sort of redirection mechanism. Actually, in this case, I'm pretty sure we're not looking at an N-tier architecture... If we are, you'd have to rsync the PHP scripts, but that's about it. There's no heavy lifting going on in PHP -- Just splicing an extra array super-structure into part of an existing single result row. BEFORE: $result = mysql_fetch_row(); AFTER: $result = mysql_fetch_row(); $pictures = array_slice($result, 3); $result = array_splice($result, 3, 3, $pictures); I suppose you could unset($pictures) to free up a single array of 3 strings, if you want to get real anal about the RAM... > I also tend to think that the database would be faster. Perhaps the > PHP > script would only a few milliseconds longer than the database to > process > the data, but when you have multiple requests per second, those few > milliseconds can REALLY add up. I'd rather spend the processor time on > the webserver gzipping the data as it goes out. Of course, I have no > benchmarks telling me that PHP would be slower than a database server > for messing with data, I'm just making an assumption. Your assumption is correct, in general. The DB should do any FILTERING / SORTING of large-scale data. But there's no way you're going to construct a SELECT query to get back an array of SOME fields from a single row pre-populated in PHP that will work across SQL platforms, and even if you get it to work in one specific DB, it's going to be a close call as to whether there's any savings at all in the DB building an array so that PHP can detect that array and build that array in C, and a couple calls to array_s[p]lice to build that array in PHP code. NOTE: The issue of having 3 fields named 'picture1', 'picture2', and 'picture3' being a sure indicator of a badly-designed not-so-relational database schema is being completely ignored here, until now... :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
