Re: MySQL Queries - Full Question This Time :)
by Nathan <natelyle(at)chartermi.net>
|
Date: |
Thu, 24 Jan 2002 21:52:43 -0500 |
To: |
"rudy" <r937(at)interlog.com> |
Cc: |
HWG Techniques Email List <hwg-techniques(at)hwg.org> |
In-Reply-To: |
rudy |
|
todo: View
Thread,
Original
|
|
>if in fact you have a category (CLA=classics?) code embedded, you would
>want to take that out into a separate column, and then assign unique
>numbers as keys (use mysql's AUTO_INCREMENT for this)
I managed to redo the structure in this regard because it seemed like a
good suggestion. :) It's helped speed up things a little bit, by allowing
a slightly different grouping method.
>if master.ID = artist.ID represents the entire join condition between those
>two tables, then either each artist can appear only on one album (doesn't
>make sense for a music collection), or each album is keyed to the artist's
>ID (doesn't make sense either), or, as i must conclude, the ID is actually
>the album ID, and therefore there must be artist redundancy, with the same
>artist appearing in the database multiple times, each time with the master
>album key
The later of the two. ID is album ID for all three tables. Artists are
redundant (not how that sounds though!) and I'm not quite sure how to
restructure the tables without having to wade through a *ton* of data
already entered. My thought was to have each artist have only one entry,
and then just a list of album ID's that that artist appears on. Can MySQL
do arrays?
>note the use of DISTINCT to get unique artist/type combinations
I've been playing with just adding DISTINCT and that seems to have sped
things up a hair too.
~ Nathan Lyle
Email: natelyle(at)chartermi.net
Phone: (906)485-4806
http://www.nathanlyle.com
"Those that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Ben Franklin
HWG hwg-techniques mailing list archives,
maintained by Webmasters @ IWA