Setting up a database input

[Champak]

I have my main app that is a media player amongst other things. the media player plays by ways of playlists read to an array. What I want to do is create a secondary app that compiles a database of my mp3 and sets them up as a list of

1/ artist - containing paths to ALL their songs

2/ albums - containing paths to their songs

My main app can then grab all songs listed under the artist or albums. So when i look in my main app, depending on the query setup in my settings, i see either all artist names, which will load all songs by that artist; or all albums listed, which of course would load all songs on that album. I'm looking for suggestions on how I should set up the database.

I was thinking of using the registry. Have two separate registry folders and in the them use REG_MULTI_SZ. One folder for artist, which will contain all artist in my collection and one for albums. In each will contain a "database" value name, artists/albums. The database values will have a list of the artists/albums. Then in the folders multiple REG_MULTI_SZ. Album title values containing paths to all songs under that album, and artist name values containing all paths to songs belonging to that artist.

My main app would read the database value and load its contents into a combo box in the app. Then I could select an album/artist from the combo and it would find that entry in the registry and load its contents.

I figure if its set up this way it will be cleaner and easier to edit whenever I add or delete songs through the main app and not worrying about structures, parsing, delimiters, and string searches. It would also be the fastest, besides the initial compiling which would only happen once.

Thoughts? A better way?

Edited February 2, 2014 by Champak

[JohnOne]

A simple sqlite db would be simpler and portable.

I'm not sure using the registry as a makeshift database is a godd idea.

[jchd]

Good reading.

Edit: I agree that abusing the registry for massive applicative data is an utter perversion.

Edited February 2, 2014 by jchd

[Champak]

OK, I'll use SQLite. I've always seen it in the helpfile but never paid it any attention thinking I needed some type of server. I haven't used database stuff in about 9 years, and that was web based server stuff, hence my original thinking. So using this would be as fast as the registry even though everything is contained in one file?

 

Good reading.

Edit: I agree that abusing the registry for massive applicative data is an utter perversion.

 

LOL, sorry I upset your sense of sensibility. Just for arguments sake, what was wrong with doing it this way? I fail to understand (and don't use the excuse that I could mess up other things in the registry by accidental edit). I do understand that the registry is generally used for settings, but it is a database that's available that can contain general data.

[jchd]

While the registry includes an ACID machinery to avoid concurrency issues, it offers none of the data manipulation possibilities that a genuine DB engine has built-in. It doesn't include space management either. So it's excellent at what it is aimed to, i.e. storing settings and basic parameters, but certainly not massive data.

Define "fast".

[nullschritt]

OK, I'll use SQLite. I've always seen it in the helpfile but never paid it any attention thinking I needed some type of server. I haven't used database stuff in about 9 years, and that was web based server stuff, hence my original thinking. So using this would be as fast as the registry even though everything is contained in one file?

 

LOL, sorry I upset your sense of sensibility. Just for arguments sake, what was wrong with doing it this way? I fail to understand (and don't use the excuse that I could mess up other things in the registry by accidental edit). I do understand that the registry is generally used for settings, but it is a database that's available that can contain general data.

First of all, there are limits to the length of data that can be stored in a registry value. Secondly, because the registry is not designed to be used as a database, concurrent read/write operations will be significantly slower than retreiving the results via a database engine. Thirdly, it bloats the registry, this slows boot time, and any app that trys to enumerate this excessive amount of data can become unresponsive. Fourthly, as stated, there are no tools built in for sorting or manipulating data.

[jchd]

... nor joining tables on complex conditions, nor fancy LIKE, nor group updates or deletes, nor result sets, nor triggers, nor foreign keys, nor grouping, nor scalar functions, nor aggregate functions ...