wolf_dude

How complex will you allow these searches to be? Could they potentially involve JOINs, GROUP BYs, and/or HAVING clauses? If so, then you really might need to create an actual persistent table. I had to do this for a project once. I don't know if our solution was really the best, but it worked for our needs, so I'll share it with you. Each search result was dumped into a persistent table. The searcher could re-order their results, page through them, or apply additional filters. All this was done through basic 'WHERE', 'ORDER', and 'LIMIT' clauses on the search result table. We used cron jobs to delete the tables after they expired. To track that, we had an index table for the searches that included all the search parameters, a randomly-generated name for the table (preceded by two underscores, so a human could easily tell what those tables were) and an expiration time - typically about 15 minutes from the time of the search, but the expire time kept getting reset whenever a searcher paged through their results. We had a cron job that would go through the records in that table to determine which ones had expired and would then drop them. However, if they had just been searching a single table - even a large one, so long as all their results were on a single shard (will you table be sharded?), we would have just used indexing on the searchable fields and let MySQL's built-in optimizations handle generating the results each time the user paged through them.

Objects tend to work well when you can think of them as a unit of something. They can be concrete, like a record in a database, a group of records in some sort of list or table, or more abstract, like a template. The over-arching principle that applies in every case is that an object will do different things depending on how it was set up - as in what properties it has. This allows your scripts that interact with the objects to be written without needing any knowledge of how the object works - it can simply create the object with the correct data, and then tell the object to do something (i.e. call it's methods). The benefit to you as the developer is that your code is easy to read, and you can separate out the logic into the classes, where it can be reused (or debugged) more easily and extensibly. In this case, I would recommend doing things from the perspective of a 'User' class. In the script that processes your registration form, you could treat your User like so: $user = new User(); $data = array('first_name'=>$_POST['first_name'], 'last_name'=>'$_POST['last_name'], 'email'=>$_POST['email'], 'password'=>md5($_POST['password'])); $user->data = $data; //set the 'data' property $user->save(); //save the new user to the database The advantage is that later on, when they log in, you can have code like: $isLoggedIn = $user->login($_POST['email'], $_POST['password']); if(!$isLoggedIn) { /*do something*/ } else { /*do something*/} After calling the 'login()' method on valid credentials, the $user object will have its 'data' property set by retrieving the relevant DB record, and so then you can access other info about the user, update that info, check permissions, create orders - all by accessing properties and methods that you create on the User class. If you'd like to learn from a book, the best I've found is PHP: Objects, Patterns, and Practice by Matt Zandstra. It's one of the yellow Apress books, and it's now in it's Third Edition. OOP didn't really "click" for me either until I read that book.

Hi. I'm a ZCE, and pretty much a fanatic for PHP. If you attend ZendCon in November, you might run into me. Looking forward to participating in the forum.