Slashdot Mirror
Simple Database Interfaces for Unix?
Siddly asks: "OK, I've used databases in DOS, like dBase2, dBase3 and others. None of those mentioned needing a knowledge of database theory, they allowed you to layout and manipulate data quite easily. In Linux, we have MySQL, Postgres, SQLite, and more. None of these are intuitive, even the GUI's aren't very helpful to any casual or very occasional user, who just wants to create a simple database and forget it until something significant needs to be added, deleted or amended. I obviously don't posses the skills or time to undertake writing such an animal. Does anyone else suffer this frustration? Has anyone managed to get something like dBase3 working under dosemu?" The problem isn't necessarily the underlying RBDMS, but the interface presented to the user. Are there front-ends for the various Unix database offerings that simplify database concepts to the level of what a dBase3 user would feel comfortable with?
First of all, just read the first few chapters of MySQL & mSQL by Oreilly and you'll be on your way with "all that database theory" stuff. It's pretty easy actually. I learned how to manage an RDBMS at a fairly young age, especially for a simpler database. If worse comes to worse, Open Office does have some Databasing possibilities. In the end, the tools are out there, you just didn't seem to look to hard. There isn't that much to learn, and you would have found that out if you had tried to learn. The database that you seem interested in making (which I hope is simple, because you can't get away from something like MySQL if it's even just a mid-sized) shouldn't cause you any problems with all of the tools available.
While I agree with a lot of what you are saying, it sounds like this guy is interested in making use of a card file, not a database. I'm a huge proponent of proper relational design (and keep an close eye on the D4 language's progress, since it corrects several flaws in the SQL language). However, there is a huge population of people who basically need an overblown card file to store some facts. Hypercard had an excellent system for doing so, and I find it odd that there are no semistructured databases similar to that available.
Asking yourself "what is truth" makes sense when you are setting relations in stone. I suspect this guy could get away with a semistructured database that dodges the bullet with flexibility and simplicity. Using a relational database to file recipes is like using a exotic sports car to drive across the street. Perhaps walking makes sense, sometimes.
I also take issue (ah the designer gets loose) that song title had better not be an attribute of a track because of covers. That statement is incomplete. Song titles can be the same, even if they are not covers, so the song title is nothing but a decoration as far as relationships. Even considering it brings peril. However, I doubt any user would be happy if they couldn't *search* upon titles. This common reasoning flaw is why I'm a huge proponent of non significant primary keys: often what appears to be useful in relationships turns out to be unreliable in the longer term.
Also, most MP3 databases only handle tracks. While attempting to handle songs, opus, introductions, etc, it would be best to handle those as a layer on top of the track table: that makes no changes to the track table, howevever. In that light, we have multiple truths, and they can be simultaniously expressed. Similar with albums: they are collections of CDs, meaning two layer, "CD" and "Album".
In regards to artist being an attribute of a track or song, if song is a collection of one or more tracks, I would be careful about not giving the flexability to store it at the track level: if the three sopranos sang three parts of a song, and they broke it into three tracks, I would lean towards relating tracks and artists, and having songs pull the aggrigate artist list from all tracks involved.
Down designer, down....
Sig under construction since 1998.