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?

Every language needs a database.

[Futurepower(R)]

This is a major hassle for me, also. Every computer language needs an associated simple database. There are many, many applications that require storing data in an ordered way that don't require a highly scalable enterprise-quality method like PostgreSQL. For example, it is convenient to store error messages in databases.

It's worth saying again. Every complete computer language should have a simple database and database administration tool as part of the definition of the language. Microsoft's FoxPro is an example of a small database. It can find any record in a million-record database instantaneously. But it is very proprietary.

Easy

[Mork29]

First of all, just read the first few chapters of MySQL & mSQL [oreilly.com] 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 [openoffice.org] 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.

Re:Every language needs a database.

[Mork29]

Porting problems. I like having my program and DB not rely on each other. If I'm taking an app and porting it from Perl to PHP, I don't want to have to completely re-create the database. Besides, languages like PHP have integrated APIs for most of the leading databases anyway. They encapsulate alot of the functions you'd have to deal with into the language. Easy to learn, quick to use, easy to port. Don't try and fix something that's not broken.

Re:Intuitive GUI?

[BenjyD]

It's right there in the post - he doesn't want something advanced. Have you seen the way Access is used in a lot of organisations? As an undergrad I did some work for charities creating databases and forms etc. Typically they have a collection of database files with maybe a few hundred to a thousand entries each - customer names, addresses etc. All they want is a program that lets clerical staff add entries, edit existing ones and churn out labels, mail-merge letters and reports. All with some sort of simple GUI. The chances of the staff learning SQL were about up there with them learning Swahili.

From what I've seen, MS Access is used for most of this. It's horrible to use, buggy and ugly, but it's just about simple enough that a non-techy can muddle through and get work done.

I think Rekall [thekompany.com] is meant to be quite good, although I know nothing beyond the dot.kde.org post on it.

Re:SQLite home address

[Ed Avis]

SQLite boasts of being typeless, and having no checking that a column declared of type integer really does store integers, for example. But for me this defeats one of the main reasons to use a relational database - strong type checking and validation. SQLite also doesn't support check constraints so there is really nothing you can do to fix this.

Re:Yes!

[canadianjoe]

Maybe just web forms might work? Not sure reports will go, but works great for data entry. PHP seems to play nice for postgres, although I don't have any personal exp with this.

Re:It's about truth, not tools

[Godeke]

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 [alphora.com]'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....

Re:If you are not comfortable with database UIs...

[Cecil]

they knew how to use the VC++ Resource Editor to create dialogs but didn't feel comfortable writing C++ code

And what's wrong with that? There's a perfectly viable alternative for those people: VB. They may not be CS majors, but that doesn't mean they should have to contract a programmer if they want to write a silly little program for something or other. The hard part of most userland programs is the UI, not the code.

Some people don't care about database normal forms and other shit that doesn't *really* matter when it comes to simply getting the job done.