> > You can probably figure ways to streamline this, but I think it > may answer > > your basic question. The best solution is one that works for you > > reliably, > > and there have to be at least 50 ways to do this. This is just one. > > Hmm. Personally I would have thought the best way to do this is to get the > db server to perform as much of the selection work as possible, thus the > suggestion of using a BETWEEN operation in a WHERE clause of an SQL > statement. 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. I did forget to include an "order by weight" clause in the query which would be required for my solution (and would add an overhead), and probably not required for the DB solution, hopefully he figured that out. Bottom line the real "best" solution is the one that works for him, that he understands and can change if needed. He probably would have a tough time measuring things that could cause the DB approach to suddenly not be able to use cached contents, like DB server load from other applications, etc., and if he is processing multiple shipments.... factors outside his control, like other apps, could impact his applications performance. Warren Vail -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
