[snippage] > In theory perhaps, the "better" approach kind of depends on if he is > looking > up the cost of one shipment or many. Databases, like you indicated, are > optimized for looking up this kind of information from large record sets > on > a hard drive and a good database will try to cache as much of their last > result as possible for use in the next query, but once cache cannot be > used, > performance drops dramatically. For one lookup on an single order, the > direct DB approach probably would produce faster results, but I doubt the > user would be able to see the performance difference on one order (can you > see a savings of 200 milliseconds), and for processing multiple shipments, > avoiding multiple db lookups would produce faster results. [snippage] All valid observations. My point, if I have one, is that many people overlook the fact that database servers are not just a convenient place to store data, but also usually the best tool for criteria-based data selection; best summed up by the phrase: "Why return unnecessary rows when you can return the right row(s)?" This implies sensible table design, and for large recordsets, heavily relies on appropriate indexing, but the truism remains: any work you can get your db server to do prior to working on the recordset in your scripting language is usually A Good Thing. Note the use of the conditional term 'usually'. Much warmth, Murray http://www.planetthoughtful.org Building a thoughtful planet, One quirky comment at a time. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
