Databases aren't scary. See why in this short demo.

[guinness]

Well if you think in terms of a flat file e.g. INI file then perhaps it becomes a little easier to understand

[Library]
1=Meshuggah,Bleed,C:\%USERPROFILE%\Music\Meshuggah\Bleed.mp3 #Artist,Song,Location
2=Enter Shikari,The One True Colour,C:\%USERPROFILE%\Music\ES\TOTC.mp3
3=Kid Cudi,Day 'N' Night,C:\%USERPROFILE%\Music\KCudi\Blah.mp3

[Playlist]
Playlist1=1,2,3 # Songs 1, 2 and 3 from the library section
Playlist2=2

The above example is a simple flat file structure in which if I were to add a new song e.g. Artist, Song, Location, I would simply increment the key up by 1, therefore the next value would be 4, 5 etc... Then I have a playlist section in which I use the key as the name of the playlist and then the value as a list of songs which correspond to the key in the library section. Make sense? 

So in a relational database this could be mapped by having two tables for both sections that denote the information about a particular song (artist, song, location( and playlist (name), then we have a third table in which we bind which playlist a particular song belongs to.

Library
- id (primary key or INI key in our case - this is a surrogate key, as it's auto-generated by the DBMS)
- artist
- song
- location

Playlist
- id (primary key - this is a surrogate key, as it's auto-generated by the DBMS)
- name (the INI key in our case)

Then we have a third table to bind the playlist and song together

Playlist_Library
- playlist_id (foreign key to the primary key in the playlist table i.e. a link to get the name of the playlist)
- library_id (foreign key to the primary key in the library table i.e. a link to get information about a song by using a single value)

Note: There is no primary key here, as playlist_id & library_id are a composite key, which make up a primary key*. But don't worry about that for now.

* A set of attributes which guarantee they will be unique throughout the entire table e.g. a social security id would be one, as it's pretty much guaranteed no two rows will have the same id and thus it's easy to distinguish between the two rows.

The data would then look like this: (The pipe character is just to denote each column in the table)

Library
id | artist | song | location
1 | Meshuggah | Bleed | C:\%USERPROFILE%\Music\Meshuggah\Bleed.mp3
2 | Enter Shikari | The One True Colour | C:\%USERPROFILE%\Music\ES\TOTC.mp3
3 | Kid Cudi | Day 'N' Night | C:\%USERPROFILE%\Music\KCudi\Blah.mp3

Playlist
id | name
1 | Playlist 1
2 | Playlist 2
3 | Awesome songs

Playlist_Library
playlist_id | library_id
1 | 1
1 | 2
1 | 3
2 | 2

Phew, glad we got here. So does it make a little more sense now?

Note: I have added a couple of keywords which I suggest you go and search, such as primary key, surrogate key and foreign key to name a few.

[James]

Basically, yes.

[guinness]

Basically, yes.

Be a little surprised if you didn't =)