Hi trexx,
Thank you very much for the feedback.
It was actually using "explain" that brought me to make this post. I've been studying it but I'm still uncertain on a lot of things. I don't have any benchmarking tools so I pretty much just go by rowcount on the explain statement to gauge how I'm doing. If I query by the pri key it will usually be one row. I am wondering if it is an increase in speed to have it find the same using the unique Songid+Song_title index. They would each be one row but is the combo more "blatant" and therefore faster?
I guess my most important question is the first one regarding how to "relate" common fields. If I have a SONG table with SONGID as PRI and it also contains BANDID which is PRI in the BAND table, is there a general rule to consider since they will be referring to each other back and forth so much? I've been using queries like:
SELECT s.song_title, g.genre, b.bandname from song s, band b, genres g WHERE s.songid='$songid' AND s.bandid=b.bandid AND s.genre_id=g.genre_id
Is that an instance where a foreign key would come in handy? If so, is there an alternative when using a MyISAM table? When you see a query like that do you automatically think "Hmm,..that looks like a good time to use ______.
INNER JOIN/UNION/FOREIGN KEYS/HAVING/OUTER LEFT INNERMOST RIGHT CROSS GROUP JOIN?
Sorry, I've been crash-coursing normalization for weeks and it's all starting to blur. :eek: 😕 :queasy: