Adrian Noland wrote: > When it comes to choosing which columns to index, you want to pick
something with a high cardinality, or, for lack of a better term, "uniqueablity". Gender wont have a high cardinality because there are only 2 choices for many records. Last name on your personal family address book will have a low cardinality because of family members sharing last name. A key of last name + first name will have a high cardinality and will make a good index.
Thanks for the explanation. I will index based on that. I decided to go with the temp table approach for now as this lets me work with queries that I can comprehend. I a past post I wrote that I merge the arrays that I get for each table. While I in fact did that, I really need to do an intersect to create an INNER JOIN. I filter each table based on the contents or ranges of particular fields and only those items that have at least one row in each table are the ones that I want. Two tables can have only one row per item by design, so the distinct will come into play for only one query. With that I also do not need an array_unique as the intersect cannot have duplicate values.
Good stuff! David _______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
