How to structure tables for songs and playlists?
My thought was to create a table of playlists titles and id's then a playlists songs table that holds the songs unique id and the playlist which it belongs to. The other plan a new table for each playlist and store song information in each table for the playlist.
Would this be a good approach or is creating new tables bad for performance or any other reason?
How about something like this?
Songs:
id title length artist_id
Artists:
id name
Playlists:
id title user_id
Playlists_Songs:
playlist_id song_id
Users:
id name email
In terms of relational design, you need two tables for playlists, one holding the playlistname (key, playlistname), one for the actual playlists (key,playlistkey,trackid)
Table for tracks holding mp3 tag details (key, track title, artist key, album .... Etc)
Table for Artists (key, name, band). You can break it down further applying the principle that you should not duplicate data for instance holding a playlistname in more than one table. By creating views, you knit all this together
However, if you are using android, this database already exists.
Related
I have the following album table:
album_id(PK)
album_name
artist_name
year
songs
My candidate keys are {id} and {album_name, artist_name}.
Now I am going to normalize the table till 3NF, and I would like to know the reason behind the data of artist_name column being redundant.
1NF
Goal: columns should be atomic.
Result:
album:
album_id(PK)
album_name
artist_name
year
song:
song_id(PK)
album_id(FK)
song_name
2NF
Goal: No partial functional dependencies of non-prime attributes (columns that don't exist in any candidate key) on candidate keys.
Solution: I couldn't find any partial functional dependencies.
3NF
Goal: No transitive functional dependencies of non-prime attributes on candidate keys.
Solution: I couldn't find any transitive dependencies.
Problem
Although the tables above seem normalized, there's the following problem: the data in the artist_name column is redundant. An artist with multiple albums will have their name stored multiple times, which we are against.
What am I missing?
i would create a table called artist and in there store the artist id and name and in the album table have a reference to that using a foreign key constraint. So where you would have artist name in album this would change to artist id. It wouldn't be a issue if you just have the name like you do now but if you have additional data that you would need to store for a artist then you would have to create the table anyway which would break the current design as you would have the name in the album table and the rest of the information in the artist table.
The main goal of normalization is to reduce redundancy. With the artist name being in the album table if you ever needed the name of a artist and additional artist info then you would have to include the album table and the artist table which wouldn't make sense and you wouldn't have any other columns besides name to link the tables together or duplicate the data in two places both the album and artist table which would violate the 1st normal form.
Also, with the name being in the album table your data would be split across two tables. The artists name isn't really a dependency on album but on the artist entity. This violates values stored in a column should be of the same domain principle of the 1st normal form.
hey i just want to create a table for photo .which has a column that can store multiple type like it belongs to the (wildlife, nature ,adventure..etc) and the tags liks with its own table for the table updation record
You can go ahead keeping 6 columns.
photo_tag_id, photo_tag, photo_links, photo_created_date, photo_updated_date
This table would be unique on photo_tag_id and photo_tag primary indexed on photo_tag_id and secondary indexed on photo_tag columns while storing data in MySql. You can always update based on filter condition of photo_tag_id and photo_tag.
photos:
id,
who, when, where
tags: -- this is a many:many mapping table
photo_id, -- join to photos.id
tag VARCHAR(99)
PRIMARY KEY(tag, photo_id),
INDEX(photo_id, tag)
The column tag could have wildlife, nature, adventure, etc
If, by tag, you mean a category, and a photo is in only one category, then it would be done differently: add category (or category_id) to photos. This is a 1:many relationship.
I am developing a web based music application. I get struck into a confusion related to MySQL columns.
Problem is like this:
I have album table:
album_id
album_name
album_year
Now the problem is: an album can contains multiple tracks (identified by track_id). Now how to store multiple track id's in album table?
I am novice to MySQL.
You have to create another table, lets name it album_has_tracks.
It has following structure:
album_id track_id
1 1
1 2
1 3
2 4
2 5
2 6
That is named relations and that is one of the point, that MySQL is named relational database. Both of the album_id and track_id are foreign keys and represent columns with their ids. After that, to get the data of the tracks, you have to use JOIN. So that are the basic you have to read about.
I would suggest you to read some basic about relational databases, for example here.
You need to find some tutorials on relational database design.
You wouldn't store the tracks in the album table, you would create an album tracks table with, for example, track_id, album_id, track_name
The album_id in the tracks table would be set as a foreign key linked to the album table and you would set its value in the track entries to the matching album_id from the album table.
I'm making a database which includes artists, albums and songs. I have a table for artists (artists), for albums (albums) and for songs (songs). The album table has a foreign key from artists, the artist_id so I don't have to write the artists' names over and over again.
Now I want to add songs. I exported tag values of my albums to csv files. These I imported into mysql. That's the songs table, it includes: title, artist_name, album_name, time.
Now I want the songs to be linked to the corresponding album. So the column album_name from songs is album_name from albums. I don't know how to link them, as far as I know foreign keys need int. In albums there is album_id but that can't be included in songs, if I wanted to I would have to put them in manually, that's a lot of time.
I think you should refactor your songs table and replace artist_name with artist_id and album_name with ablum_id, which have a foreign key constraint on artists and albums tables respectively
Another way of looking at is:
the albums table is essentially a junction table between artists and songs. You could have called the table artists_songs to reflect the relationship.
In this case, your junction table should have both artist_id and song_id.
So the relationships will be
artists have many albums (or artists_songs), have many songs via albums
albums have many songs, belong to artists
songs belongs to albums, belongs to artists via albums
I was wondering if there is some way to combine two indexes into third to make sort of serial number... For example:
If I want to create music database
I would start with table artists with
-artist_name
-artist_id (Primary key)
-....
Then table albums with
-album_name
-album_id (P.k.)
-...
And then table songs with
-song_title
-song_id
Let's say artist would be X with artist_id - 12345
Then album Y with album_id - 678
And I want song_id to be 12345.678.xxx (dots only for visualization of the idea, length of artist_id and album_id would be constant)
My question is. Is something like possible?
Because I have a feeling that this would perform much more better search through database.
Not only that in my song_id I have full information of artist and album (I don't need to use foreign keys than), it should speed up any query about songs from the same album or other albums of the same artist. All information in one index and it needs only some kind of extraction.
Or maybe its just mine minimal knowledge about MySQL? :)
Keep artist_id and album_id as separate columns in the songs table and include proper foreign key relationships and indexes. This will give you the best combination of data integrity and query performance.