treeleaf20 wrote:I was told that actually running a query and then running it again in a loop would be better because it go and grabs a result and then grabs another result in the loop. I wouldn't mind seeing what you mean by
I appreciate the continued help.
This is probably a good time to start thinking about RDBMS (Relational Databases, simply put) and how you should set up your tables to reap optimum performance. I'll try to keep this as simple as possible. Basically, MySQL works a hell of a lot faster in retrieving results when you have keys/indices on your tables; it makes it much easier for the engine to find what it's looking for. Further, by utilizing primary and foreign keys, you can link your tables together, virtually eliminate data redundancy (storing ANY of the same information, excluding key columns, in more than one table), and dramatically reduce the amount of code (and processing time) required to execute your queries.
For example, you have a users table. In the users table, you have a primary key field called email (primary key values have to be unique - obviously no two people can have the same email address, so it works well as a login qualifier, too); you also have columns named name_first, name_last, and country.
Now, suppose you are writing your own blog or something, and next to each post, you have a link that takes the browser to the poster's personal "bio" page, and you have PHP code to query the users table to output information about the poster. Assume you want to output the user's first name, last name, and country of origin. The first and last names could be pulled from the users table, but when you consider the country column, we run into a problem. Say you have "Unted States of America" for UserX's country in your table row, and that mispelled "Unted" came from some drop-down menu you had in your profile creation page, which then populated the database upon submission. Maybe you've had your site up for months, and there are thousands of people who now have mispelled countries of origin.
Sure, you could easily run a query to fix the typo row each row, but my point is that rather than hard-code the country value into each row, cluttering up your user data table, it's wiser to use something like a numeric INT value to describe the country to a related table that contains the actual names. For example, the INT value 216 might stand for "United States of America" and would correspond to a row in your new table (see below). The way you'd link your tables is pretty simple. You would create a second table called countries and the primary key would be country_id. Then, when you queried a user on your bio page, you'd do something like
$query = '
SELECT users.*, countries.* FROM users
LEFT JOIN countries ON users.country = countries.country_id
WHERE email = ' . $_SESSION['auth']['email'];
$result = mysql_query($query) or die('Dead.');
$row = mysql_fetch_array($result);
//Now, you have access to all the data from both tables within a single result set.
//If you want name, it's just $row['name_first'].
//If you want country, it's just $row['country'].
//Sweet as!
You now have the flexibility to add any number of neat features to the bio page, such as the population of the person's country of origin (which you would just add as a new column on the countries table). Do you see where I'm going with this? You can split your tables up very effectively and efficiently if you spend the time to do it right the first time, and doing so gives you immense power through the use of your queries. This is just a simple example, but when you start getting into more complex queries, you're going to wish you had concentrated considerable effort on designing your database.
Hope this is helpful!
