Simple Database Interfaces for Unix? 96
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?
TOra (Score:2, Interesting)
Its aimed more at Oracle, but will work wth MySQL and PostreSQL.
I use it mainly for inputting and modifying data in a sensible way.
CLI (Score:1, Interesting)
Regardless of your background you obviously aren't a DBA.
A real DBA uses CLI. It's a well known fact that there is no consistant GUI among different vendors, and in many cases in different version of the same product. We don't look for point and click to perform a task, we'll do it by a list of scripts that we prepared for various tasks and customize them - from scratch(creating database, tables, triggers) to maintainance(expand database, add users, check deadlock, etc.)
I don't know how you could forget the usage of SQL so easy, SQL is made to ease the access of RDBMS, and if it complies to standard, same SQL statement can be used in different RDBMS.
I've no recommendation of GUI frontend for you but I recommend you to look at the SQL reference of the RDBMS of your choice. You'd find GUI hinder you when you get used to SQL statements.
Re:Every language needs a database. (Score:3, Interesting)
For what it's worth, PHP 5 will have the SQLite [php.net] embeddable database engine bundled by default. Which means that you won't have to install a separate database engine for lightweight SQL database tasks.
JP
It's about truth, not tools (Score:5, Interesting)
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.
Is there anybody here over 35? (Score:4, Interesting)
Back before SQL was available, mainframes had lots of data accessable via TTY terminals. It was an entirely different method that is rarely in use today. Most existing systems have had a thick client or web interface slapped on the front. When databases moved to those new fangled PCs with loads of RAM - 64k of memory - and loads of storage - 100k discs - they reflected the mainframe way of doing things.
dBase ][ and III were great apps for their time, totally tied to a character terminal, and often the stucture of the database was tied into that character terminal. If you gave a field two characters, there were two character cells on the screen devoted to it. Each screen was a record. Configuration was done with a simple interpreter. Gads - the dot commands... I can't remember a single command, but I remember the periods. Everything else was a field.
Basically, you made a UI. The UI *was* the database, and each time you filled it out, that was a record (keyed by a field in the form? It's been too many years). It's easily doable with SQL (which is why SQL is considered more powerful), but a really really simple front end, a la dBase, I haven't seen.
If you haven't done it, you're likely to not see much of a big deal. It's a shift in thinking more than anything programmatic. Kinda the way unix has "everything is a file", the dBase way might be "the form is the database". Both are gross oversimplifications of how it actually works in practice, however.
There's a more modern db (circa early 90s) that runs in DOS that is dBase like. I can't recall the name, but it was a diehard app with users persisting (probably until today).
--
Evan
He could be on to something, here! (Score:3, Interesting)
I really don't remember much about programs like dBase, other than editing and viewing .DBF files with utilities such as PC Tools, so I could be wrong on this. My vague recollection is that dBase provides a "serverless" database -- a DBF file that can be easily moved from one machine to another without exporting (a la mysqldump), and without the requirement of a heavyweight server continuously loaded into memory. These DBF files could be easily manipulated with simple software programs, or manipulated programmatically with libraries.
It sounds like what the poster wants is a piece of software that would conceptually lie between the lightweight UNIX db/dbm/ndbm/gdbm databases and the heavyweight server-based databases like PostgreSQL and MySQL.
As a programmer, I've often wished that I've had some simple way of storing complex data without having to roll my own solution, or rely on PostgreSQL/MySQL. Also, I have a web designer friend who would love to be able to use database-aware Perl CGI scripts without having to use his web host's SQL servers. (For small applications that REALLY don't need the full power of MySQL -- like banner rotator scripts.) I figure if this hypothetical serverless mini-database could support an SQL parser and have a DBI-compliant DBD driver... presto!
I'd volunteer to whip up an implementation of this idea, but my software to-do list is already enormous. :)
Yes! (Score:5, Interesting)
I'm not the original poster, and I know a bit more about modern RDBMS, but I would still appreciate a similar front-end to what he is talking about, for Unix.
Currently, my company uses MS Access for employees to perform data-entry to our Postgres and MySQL databases. We don't plan on keeping our Windows boxes around forever, and we plan to migrate away from Windows and MS Office, so we need a replacement. We've got everything covered, sans MS Access.
I need something that any idiot can use to make forms for data-entry. Does such a beast exist for Unix/Linux/OS X?
Re:Easy (Score:2, Interesting)
Why would I bundle a particular database with my software? If I did that, I would be free as Microsoft allows me to be.
MSDE is a feature installed on almost all XP systems and provides a replacement for Access functionality but I would still prefer to use SQL92 and compliant with almost everything.
What about Berkeley DB? (Score:2, Interesting)