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?
Perhaps you should try DBDesigner which is quite intuitive, easy to handle, etc. :-)
You can export everything, create a webfront in php, etc.
I use it for my database-class..
It's free, it's os independent. what else do you want?
Under UNIX, people traditionally use the file system as the database. It's an intuitive, hierarchical database supporting many of the features you expect from databases. You get hierarchical string-based keys and arbitrary binary content (up to many Gigabytes per key). This works best with ReiserFS, but works well enough with the other file systems as well. And everything knows how to access the file system.
The next database system people use a lot is dbm and its variants. They are good for when you need to hold lots of tiny data items and you need high performance. If your data items are big or you don't need high performance, go back to the file system. Dbm is, again, intuitive, simple, and powerful. And it's accessible from lots of different languages.
If you want something close to an RDBMS without using an RDBMS, have a look at Metakit.
Altogether, I think UNIX/Linux developers should mostly stick with using the file system as a database.
None of those mentioned needing a knowledge of database theory, they allowed you to layout and manipulate data quite easily.
Without a knowledge of database theory, you're going to build a bad database that doesn't scale well.
At the very least, you need to know about database normalization, which comes down to not repeating data (and instead repeating keys to that data).
You'll need to know that even though databases are supposed to be "Fourth Generation Languages" ("4GLs") where you just need specify "what" and not "how", in truth there are still a number of implementation details you'll need to be aware of.
Many of these implementation details are, no surprise, implementation specific, varying from one database (or one version) to another. (Sybase, in particular, departs from many other databases with a number of quirks.) Things like how indices are physically represented, what null really means in your database, the subtle difference between a null that means that a column's value is not known and a null that means a row (as in outer joins) does not exist, how flexible views are (if the database supports views at all, you should use them, as they're one of the few ways to abstract your interface from your implementation in a database), the difference (if any) between a view and a user defined function, how auto-increments are generated and passed around, etc., etc., etc.
On a more general level, you'll find that really designing a database makes you sound like, Pontius Pilate talking to Jesus Christ: you'll be spending a lot of time asking "what is truth".
No, really, I'm being serious. A database is an attempt to model reality at some level of granularity. One of the big question is how granular a view you need to take, and how general or specific various tables need to be.
Consider a "simple" database of MP3s: is a track the same as a song, and is that the same as an opus? What about classical recording that make each movement of an opus a separate track? What about non-classical recordings that have spoken introductory tracks? One "song" or two? Is an album a CD? What about multi-CD albums, with disc one and disc two? Is an artist a attribute of an album or a track or a song? (Answer: a song.) Is a group an artist, or is it a set of artists? (Answer: judgment call, but probably the latter.) Is the composer table a sub-type of the artist table? (Answer: yes) Does your database implementation natively represent sub-typing relationships? (postgresql does, in Sybase you have to implement it yourself.) Is the song title an attribute of the track? (Better not be, if you want to represent different covers of the same song together.)
What you're doing here isn't merely telling the database that you need a bunch of tables: you're describing the "truth" that's in the world -- as you see it, and as clearly as you can see it -- and trying to represent that truth in the database.
Long before I was a professional programmer, long before I ever designed any databases, I happened to pick up a book on a bookstore's remainder table for $4.98. The book was about designing databases, and quite a bit of the text was presented as Socratic dialogues between various stock characters, arguing about "what is truth". It's been too many years for me to recall if I still agree or not with all the arguments presented in that book, but it's take-home point -- that designing databases is a search for the truth -- has stayed with me, so I suppose it was convincing.
I hope that you'll take home a point from this post: designing a database is -- or should be -- a rigorous activity that includes much testing of your hypotheses and much recourse to asking yourself what it is you're really representing -- or are able to represent. It's not something that should -- in real cases -- be easy, and having a tool usually gets in the way of really thinking about what you're designing.
Opinions on the Twiddler2 hand-held keyboard?
I found the SQLite home address on the page you mentioned: SQLite -- An Embeddable SQL Database Engine. I downloaded it and tried the example. SQLite definitely looks like it is an answer. Thanks, that's definitely the kind of database I need. I didn't know about SQLite.
SQL 92 Features That SQLite Does Not Implement. Not many.
Very fancy, and supports every language and its sister:
Is this the answer? Are there any drawbacks? Anyone have experience with SQLite?