8 messages in com.mysql.lists.mysqlRe: [PHP3] optimising a query| From | Sent On | Attachments |
|---|---|---|
| Adam Powell | 11 Jul 1999 03:34 | |
| Adam Powell | 11 Jul 1999 04:10 | |
| Adam Powell | 11 Jul 1999 09:34 | |
| Paul DuBois | 11 Jul 1999 11:46 | |
| Ariel | 11 Jul 1999 12:21 | |
| Sasha Pachev | 11 Jul 1999 14:43 | |
| Sasha Pachev | 11 Jul 1999 14:56 | |
| Sasha Pachev | 11 Jul 1999 22:38 |
| Subject: | Re: [PHP3] optimising a query![]() |
|---|---|
| From: | Sasha Pachev (sas...@direct1.com) |
| Date: | 07/11/1999 02:56:53 PM |
| List: | com.mysql.lists.mysql |
Adam Powell wrote:
What we are trying to do is take the load off the database and put it in the script. We have MANY variables associated with the banner, like weighting, size, subjects it favours, subjects it rejects, time targeting and so on... we also have a cookie-based profile of the individual banner viewer that we use to judge what would be the best banner for them to see at any one time.
The problem with all this stuff is that we cant put it in the SELECT statement, as this would make it about 20 lines long and span about 3 tables, so what we are trying to do is do a SELECT * FROM banners, and then do a loop that goes through each banner and assigns it points based on the individual criteria, and then do a bit of fuzzy random logic to pick the best one. We are moving the processing overhead from our database server to our individual banner servers.
So yes, we do need to do the entire SELECT statement, which is why I am wondering how we can reduce the load... we only have to select four individual rows from the DB, is it quicker to do select a, b, c, d FROM... instead of SELECT *? I think it is, but I am not sure by what degree.... Also, if there is a criterion that always means a banner is inactive, would it slow us down if we used SELECT a, b, c, d FROM banners WHERE weighting=inactive?
Thanks, Adam Powell, CTO - Click Agents Corporation. Web : http://www.clickagents.com Email : ad...@clickagents.com
The only time shitfing the load from the database to a script could possibly make sense that I can think of is when your database is not running on the same machine as the script. Even then, this most of the time will not be the best solution.
Ideally, you want to incorporate all of your operations natively into the database. You may consider modifying the sources of mysql to incorporate all the fancy processing. If you do not feel competent enough, or just do not have the time, you may consider getting TCX to do it for you. Don't know if the extended support will cover it. In any case, I imagine you can work out some kind of a deal with TCX to help you.
-- Sasha Pachev http://www.sashanet.com




