Fine. One bite and baby step at a time.

Tasks

  1. Script gets Artist Name and ID from Spotify and puts into artist table that stores IDs and Names.
  2. Script gets Artist(s) popularity for day one and puts it into artistPop table that has, in each row: a datetime stamp, artist id, and popularity for that date (worry about whether this is best way later).
  3. Script gets artist popularity on subsequent dates, inserts new rows (worry about whether this is best way later).
  4. Script gets artist’s albums from Spotify, uses those IDs to “get several albums” and puts into albums table with each row containing: albumName, albumID, album release date … should I have a separate table with rows containing just albumIDs and artistIDs? Or should I include artistID here? Screw it, put artistID here, too. We’ll find out if it breaks anything.
  5. Script gets album popularity for day one and puts it into albumPop table that has, in each row: a datetime stamp, albumID, and popularity for that date (worry about whether this is best way later).
  6. Script gets album popularity on subsequent dates, inserts new rows (worry about whether this is best way later). You know, I’m starting to think this might be easier than I’ve been imagining it to be.
  7. Script gets trackIDs (are those in large album objects so that I have them already?) and uses them to “get several tracks” … wait … if this info is already grabbed in “get several albums,” I could use that to … insert tracks into tracks table (one huge table for all tracks from all albums from all artists?) with each row containing: trackID, trackName … also albumID? or have another table with rows containing just albumIDs and trackIDs? … for now, let’s just go with the track table rows include albumID … and–sure, why not–artistID.
  8. Script gets several tracks to grab track popularity on day one and inserts new row in trackPop table (can there be just one big popularity table with popularity for all artists, albums, and tracks?) … (can/should there be a separate table for each track’s popularity? each album’s? each artist’s?)
  9. Script gets track popularity on subsequent dates and inserts new rows.

Is it really just this simple?

Can I, should I, separate the script/code into … creating the tables … no, wait … if …

Maybe the key is separating:

  • getting and storing the static info of artists, albums, and tracks
  • getting and storing the popularity of artists, albums, and tracks

You know what I think has screwed me up? Maybe …? All the MySQL tutorials with code that basically … checks to see if something already exists and, if it doesn’t, create a table or row … and I was thinking that somehow complicated getting and storing popularity data over time … maybe I’m now being too optimistic or whatever, but … I think I don’t need to do what I’ve been doing … or … WAIT … once I get all this crap in my database … I can easily then pull it out — if I so needed and/or desired — into my own JSON or javascript object.

Okay, now’s the time on Sprockets where we stop worrying about wasted time and get back to kicking ass.

Advertisements

About jotascript

Aiming to please. Seeking to impress.
This entry was posted in Databases, MySQL, Spotify. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s