This is a pretty basic - and maybe too broad, I dunno - question from an amateur technology guy.
Over the years I have dabbled in coding and webpage design, basically as a hobby. At various times in the last decade and a half I've attempted to get my head around databse design and normalization, though I haven't made a lot of progress there. Right now I am playing with the Raspberry Pi and teaching myself Python.
For a few years I've been thinking about using the Raspberry Pi to develop a little jukebox device that can be used in bars, complete with BMI and ASCAP reports, etc. Long before I ever actually bought myself a Pi, I started woring on the databse design. Fortuitously, one of the O'Reilly MySQL books I was using had a sort of jukebox program as an example, so that was a nice start.
Now that I actually have a Pi and have started noodling around with Python, I can see there are a number of jukebox projects in Python here on Github already. That's not at all surprising, but what did surprise me is these projects typically do not use a database. Now if I didn't have to use a databse, that would be great, so I'm wondering when I would want to use one and when I needn't bother. Big question, I know.
Most of the existing Python jukeboxes look at a volume and then slurp up all the album and track listings into dictionaries and then make them available to be played, no databse necessary. As far as I understand, this means all those track listings have to sit in memory for as long as the program is running; while with a database the program could go back and look up a track listing whenever it's necessary. Naturally, the latter would be slower than the former, but that probably wouldn't matter with this sort of application.
So now I wonder whether I need to bother with a database at all. The jukebox program would always run locally, in the little Raspberry Pi box, so there would be no network-related performance hit. The only limitation would be the memory available for the track listing, and now I wonder whether, say, a dictionary of a couple hundred albums and their tracks would really be much of a problem.
So am I over thinking this?
I think you've maybe already realized the answer - a full database is probably overkill for a small basic application.
Of course, if your goal is to understand using a database, it is a good start!
I typically break down a project into:
1. Get the basic stuff working. Keep data in memory only, especially if the dataset is small (e.g. an album and handful of tracks).
2. Once the functionality is working, consider saving and restoring the dataset to a text file - e.g. a CSV (comma separated value) or something even more basic. E.g. tracking several albums, their artist, and the tracks. I often start reading/writing to a text file when I get tired of the "run the program, open an album" test/debug cycle, add a track file to the command line. At this point I can easily play all albums by an artist, or a random selection of tracks, etc, without manually re-loading all my albums.
3. Build on the save/restore to text file. E.g. maybe I want to record "mix tracks", playing certain tracks in a specific order. Or I add different kinds of text files: albums and mixes.
4. A database becomes useful when I want to track continuing events or search for stuff between columns of data. For example, a database would be useful to: "give me all tracks by artist X, less than 5 minutes long, which I've played in the last 2 weeks". Now we're accumulating data: when did I play tracks: from which you can determine how often; in what order; favorite artists; and so on. Not impossible using text files, but a little easier with a database.
Hope that helps ...
Please follow-up to let us know how you made out. For good karma, mark a reply as the answer if it helped!