All: I am developing a search engine and using MySQL as the backend database management system. Under normal circumstances, when users search through large volumes of records on a search engine site, the results are broken down into pages. When a user clicks on the 'Next' link, the system will re-query the database and return those records that pertain to that page (records 10 through 20, perhaps). This, as you can plainly see, requires the application to re-query the same data from the same table each time the user clicks on a 'Next' or 'Previous' link. I would imagine that this may lead to some resource contention on that main table, especially when many users are using the system simultaneously.
I've never seen vBulletin's code, but I have been able to determine from careful analysis (and testing) that they employ a search table, of sorts, that contains the returned records from a search. So, when a user of the system submits a search query, the system returns the records and throws them into a separate search table, identified by a sequential primary key field. Then, the system uses that search table to display the appropriate records according to the respective search identifier (referenced in the URL), never touching the main table again until a brand new search is performed. This seems to be a pretty good way to facilitate large text-based searches. Are there any other mechanisms that can be used to build a powerful, yet quick and light on resources, search system? Is a fulltext index the best way to achieve maximum performance with this kind of search? Thanks. -- Steve - Web Applications Developer http://www.sdwebsystems.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
