For many of our advanced queries, implementing an index did not make a significant difference as the queries did not require table joins. We then decided which attribute to use as an index based on performance time. For implementing indices on our advanced queries, we tested multiple attributes as the index for each query. Returned artists in the top 50% in terms of popularity (so users can see more popular artists)Įach team member devised and developed these queries.
Returned songs from the 21st century (more relevant to our user base).Returned songs released on the user’s birthday.In order to provide another level of interactivity, we designed advanced queries that were more personal and informational, as the first step of the development process, following the creation of our tables. While these did not make it into our current iteration of Tunify, we hope to integrate these tables in the future. We initially had additional relational tables such as: ArtistGenre, SongGenre, and AristSong. This relational schema is the final database that Tunify uses. A UserGenre table, for users and the respective genres they like.A UserArtist table, which represents users and the artists they like.A UserSong table, which is dedicated to songs liked by users.A UserUser table, which is dedicated to the matches between users.The subsequent tables are meant to represent the relationships between these fields. The first few tables designate our actual fields: the artists, users, songs, and genres. With this in mind, we were able to develop a plan for our database and decide on schemas. Artists can belong to specific genres, and they create their own songs. Users create uniquely identified accounts through which they can like artists, users, and genres. Upon deciding all of our categories we were able to develop an overall design for Tunify’s backend and user story, outlined via our ER diagram:Īs demonstrated, Tunify’s database tables are tightly connected. The user collections include users, the matches they make, and the musical content that they like.
Our data is mainly broken down into two collections: music related data from the Spotify set and the user collections. To parse this data set, we used the Pandas library from Python on Jupyter Notebooks, and obtained the necessary data to populate our tables. We were able to settle on the following categories to integrate into Tunify: Artists, Genres, and Songs. To populate the database that would be necessary to build Tunify, we found a Spotify dataset from Kaggle with data on various categories involving Spotify’s data. We realized that people universally bond over music, and that we could base an application around that which addresses the current problem and brings about a positive outcome. While social media apps were useful in keeping touch and sharing information with our peers, it was difficult to meet new people this can be especially hard on university students trying to make friends. In the grand scheme of things, Tunify was developed to address the lack of social interaction amidst the current global pandemic. During the process, we learned a variety of tools and technologies while addressing various challenges in making our application the best it can be.
#Tunify gratis full#
In developing Tunify, we gained an understanding of full stack web development by developing a database schema consisting of various tables which we were able to interact with via advanced queries and triggers, a backend REST API using ExpressJS to handle HTTP requests communicating with the database, and a frontend web application designed and programmed with React. They can then view other users with mutual interests, like their profiles, and initiate friendships. Users create an account and proceed to like various artists, genres, and songs. Tunify is a web service through which users can meet those with similar taste in music. UIUC CS 411 Database Systems Final Course Project
0 kommentar(er)
