The [Title] bone's connected to the [Lyrics] bone...

July 17, 2006 1:41 PM

MySQL/PHPmyAdmin for a band: How do I easily create a repository of lyrics that can be brought in for multiple albums?

Dreamhost server
phpMyAdmin 2.8.0.3
MySQL - 5.0.18-standard-log
(I read somewhere that "Relationships are off". I tried setting up relationships on another site and got nowhere with it.)

My database background is Access, but I feel I've got a handle on the whole normalization thing and so here's where I run into problems. A band has [Albums] albums contain [Songs] which have [Songs.Lyrics]. I would like to not have a long text field for each album that has all the lyrics (and their css encoding) - also, some songs are on a couple different albums.

But how can I set up a many to many structure without relationships?

Or how do I set it up with relationships in phpMyAdmin? All the documentation seems to say not to do it, or is so advanced, I can't tell if it's relevant.

posted by Brainy to Technology (8 answers total)

My two cents... you don't really need to specify relationships at the database level like in Access. As long as the relationships are implicit in the queries you write (e.g., by your choice of using a LEFT JOIN or an INNER JOIN), you're fine.
posted by Doofus Magoo at 1:51 PM on July 17, 2006

so, 1 [Album] has many [Songs], which each have one [Lyric](bear with me). The Lyric may also be attached to another [Song] on a different [Album], correct?

This doesn't sound like a many-to-many, it is a one-to-many. It doesnt matter that an [Album] has many lyrics, because a [Song] only has one [Lyric].

I would solve this by simply attaching a lyric to a song as a one-to-many. A song has one lyric but a lyric can be attached to many songs.

So, [Songs] will have a field called LyricsID, which is a foreign key to [Lyrics]. The [Lyrics] table consists of LyricsID, LyricsContent and whatever else you need. This way, You can attach multiple [Songs] to the same [Lyrics] entry.

Does this help at all?

With a traditional relational database, you do not set up "relationships" so explicitly like you do in Access. You set up the primary and foreign keys to emulate those "relationships". Really, it could be said that Access' relationships is just a method of illustrating primary / foreign key pairs.


The usual DB solution for a many-to-many is to use a third table in between.

So, let's say that [Trainees] take many [TrainingPrograms], but a [TrainingProgram] also has multiple [Trainees]. The Primary Key of [Trainees] is TraineeID and the primary key of [Training Program] is TrainingProgramID.

You create a third table to link the two. This new table will be called [TraineeTrainingPrograms] and will consist of two fields, TraineeID and TrainingProgramID.

You can now write a SELECT query to get all of the [Trainees] in a [TrainingProgram] or all the [TrainingPrograms] taken by a single [Trainee].
posted by utsutsu at 1:57 PM on July 17, 2006

Response by poster: Doofus, So far I have been joining [Shows] to [Venues] in a pure query. But now I have the issue of having [Albums] that have [Songs] (in a particular order) that have [Lyrics]. So an album would have to be joined to songs in a many to many (with some way to keep track of the order)...hmmm, wait...i think im getting it....

Would the best way of doing this be to create a [SongsOnAlbum] table that has albumID, songID, tracknumber and then write a query that joins [Songs] and [Albums] to that table, sorting in tracknumber?
posted by Brainy at 2:03 PM on July 17, 2006

Response by poster: Oh, that second paragraph was more directed to utsutsu.
posted by Brainy at 2:04 PM on July 17, 2006

I don't get why there's a separate table for the lyrics.

Each song has only one set of lyrics, surely, so lyrics should just be a field in your songs table? Maybe you're overnormalised.

The relationships should be handled as utsutsu says, with a linking table -- I would have a table of songs, a table of albums and a linking table called something like songs_albums.

Each song would have an id, each album would have an id, and the songs_albums table would just be two columns of ids to say that song x is on album y.

This bit raised a question too:

I would like to not have a long text field for each album that has all the lyrics (and their css encoding)

I don't know what "css encodings" means but that sounds like there's some double handling there too.
posted by AmbroseChapel at 2:11 PM on July 17, 2006

Would the best way of doing this be to create a [SongsOnAlbum] table that has albumID, songID, tracknumber and then write a query that joins [Songs] and [Albums] to that table, sorting in tracknumber?

I should Preview...

Yes, that's the way.

Three columns of numbers then, the third being the track number.
posted by AmbroseChapel at 2:13 PM on July 17, 2006

Best answer: I would do it this way, adapt as you need to.

[Artists]
- ArtistID - primary key
- ArtistName
- whatever other artist info


[Albums]
- AlbumID - primary key
- ArtistID - foreign key
- AlbumTitle
- Year
- Label
- Anything else specifically related to the album


[Songs]
- SongID - primary key
- AlbumID - foreign key
- LyricsID - foreign key
- SongTitle
- TrackNumber
- whatever other info


[Lyrics]
- LyricsID - primary key
- SongID - foreign key
- LyricsContent
- Whatever else


[SongsOnAlbum]
- SongID - primary key
- AlbumID - primary key, note this is called a composite key when you use two fields
- TrackNumber

Now you just need to write some queries to be able to pull the data you need. I wrote this up assuming multiple artists, but you sound like you want this to be just for your own band. I would still keep the Artist table though, so you don't have to update every album if you need to change something that applies to your band.
posted by utsutsu at 2:13 PM on July 17, 2006

Response by poster: Ambrose "CSS encodings" was my "I gotta hurry up and finish this question or I'll never post it" way of saying that if I had all the lyrics embedded within an albums field, I'd have to hard code in the class of title, of lyrics, as opposed to letting that all come out normally from the db.

utsutsu
That's exactly the sort of visualization I needed! thanks!
posted by Brainy at 2:21 PM on July 17, 2006