Table structure for a band's 'Discography'

[toString]

I have an example layout for my table:

id / title  / parentID / isSingle
1  / album1 / 0        / 0
2  / track1 / 1        / 0
3  / track2 / 1        / 1
4  / album2 / 0        / 0
5  / track1 / 4        / 1
6  / xxxxx  / x        / x

It's not for any work/school project so it doesn't actually matter, but in terms of normalising is that good enough? I always wonder how crazy you have to get with that kinda thing... I could split it into tracks and albums, but keeping everything in one table seems to do the same job, with less effort? It seems straightforward.

There isn't really any big question, I guess I'm just looking for any other ideas, or "looks fine to me"...

 

[Inquisitor]

If it's going to be properly normalised, then it should be split up into several tables, one for each type of record. In this case, you'd want one for albums and one for tracks.

Keeping them all in one table doesn't work well because albums and tracks have different information associated with them, for example, tracks have track numbers, but albums don't.

 

[robmiller]

That seems like a really weird way of doing it :/

Surely you'd have a tracks table linked to the primary key of the albums table, then do something like:

SELECT *
FROM albums AS album, tracks AS track
WHERE album.id = track.album

 

[HTMLHugo]

could you go for ...


table 1 albums
AlbumID(PK)
Title

Table2 - tracks
TrackID(pk)
title
issingle

Table3 - Lookup table
TrackID(fk)
AlbumID(fk)


just in case a single ends up on more then 1 album (hey it does happen)

or is that wrong ?