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?

Try this GUI

[FlashBuster3000]

Perhaps you should try DBDesigner [fabforce.net] 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? :-)

GUIs for MySQL

[Wee]

I've never used dBase3, so I don't know what it's tools looked like, but for MySQL there are a bunch of GUI options.

For a straight-up GUI, he might try MySQL Control Center [mysql.com]. It's a Qt-based app, so it'll run on Linux and Windows. It lets you build and run queries, manage the server, etc. Even has a "viewer" for images stored as BLOBs.

There's phpMyAdmin [phpmyadmin.net] as another option. It's web-based, so the "GUI" should run on anything. It does the same kind of stuff that MySQLCC does: lay out tables, create fields, run queries, etc.

On the admin side of things, the upcoming MySQL Administrator [mysql.com] looks like it should be very nice. It lets you drop users, tune the DB, monitor the server, etc.

No matter what he winds up using for a GUI, if he uses MySQL, I couldn't recommend the MySQL Cookbook [oreilly.com] highly enough. It's an amazingly well-written book and very helpful. Every time I find myself with a "what's the best way to do so-and-so..." question, the answer is never more than 30 seconds of page turning away. It's also good for beginners because it's an easy way to find out how to do particular tasks without having to read an entire manual. It'll let a novice user figure out what query to type into MySQLCC, in other words. And the novice user might eventually find out that all the "database theory stuff" isn't all that difficult to learn.

That's about all I can think of off the top of my head. I'm sure some googling or trolling through freshmeat will yield some GUI apps for PostgreSQL if that's what he's into using.

-B

there are plenty of choices

[ajagci]

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

Altogether, I think UNIX/Linux developers should mostly stick with using the file system as a database.

SQLite home address

[Futurepower(R)]

I found the SQLite home address on the page you mentioned: SQLite -- An Embeddable SQL Database Engine [sqlite.org]. 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 [sqlite.org]. Not many.

Very fancy, and supports every language and its sister:

• A complete database (with multiple tables and indices) is stored in a single disk file.
• ACID (Atomic, Consistent, Isolated, Durable) transactions.
• Database files can be freely shared between machines with different byte orders.
• Supports databases up to 2 terabytes (2^41 bytes) in size.
• Small memory footprint: less than 25K lines of C code.
• Two times faster [sqlite.org] than PostgreSQL and MySQL for many common operations.
• Very simple C/C++ interface [sqlite.org] requires the use of only three functions and one opaque structure.
• TCL bindings [sqlite.org] included. Bindings for many other languages available separately. [sqlite.org]
• Simple, well-commented source code.
• Automated test suite provides over 90% code coverage.
• Self-contained: no external dependencies.
• Built and tested under Linux and Windows.
• Sources are in the public domain [sqlite.org]. Use for any purpose.

Is this the answer? Are there any drawbacks? Anyone have experience with SQLite?

Re:Is there anybody here over 35?

[shyster]

I'm not familiar with dBase, but it sounds a lot like Microsoft Access. Perhaps the poster should look into that...maybe running under that CodeWeaver's Office emulator if he wants it under *nix.

For a good bit more work, but less money and the karma boost of avoiding proprietary (and somewhat buggy) Access, it looks like OpenOffice has rudimentary support for databases. Take a look at the UnixODBC project, specifically this [unixodbc.org] PDF, which seems to do a decent job of explaining the steps involved. Note that I've never tried this, but it certainly looks workable. As a bonus, you should be able to use any database with an ODBC component.

Of course, you could always go with dBase [dbase.com] (who bought some of the rights from Borland), who have a web enabled dBase version. It'll need to be hosted on a Windows machine, it looks like though.

You may also want to take a look here [cbbrowne.com] which lists Windows and *nix xBase compatible programs. xBase was (is?) a standard that dBase, Clipper, FoxPro and others adhered to. Perhaps you'll find something there. Also, there was a dBase for UNIX at one point...I don't think it's still for sale, but you may be able to turn up a copy on eBay or something.

One last suggestion would be KNoda [knoda.org] which is a KDE frontend that allows for queries, forms, and table design. It looks a bit like Access, though, once again I haven't tried it.

That should start you on your research...good luck.

Gedafe

[swusr]

Does such a beast exist for Unix/Linux/OS X?

If you're using PostgreSQL [postgresql.org], Gedafe [ee.ethz.ch] is a very nice automatic web frontend generator. Just define your tables, views, constraints, etc. for validation and such, and it takes care of the rest. Give it a try, it's really good.

Re:Yes!

[iantri]

Yes. Rekall [totalrekall.co.uk] or here for free binaries [rekallrevealed.org] is exactly what you want. It can use Xbase/MySQL/PostgreSQL and other formats.

It's just like Access, except with an multi-window interface instead. It's also extensible with Python.

Re:Is there anybody here over 35?

[iantri]

Sorta like Filemaker [filemaker.com], where you design the forms and the database stuff is handled invisibly by the software?

It's a shame that Filemaker is only Windows and Mac..

Try Servoy!

[dso]

There's an excellent program called Servoy (www.servoy.com) that is a zero deployment client based Java. The form development is very similar to MS Access and uses Javascript as it's scripting language.

Since Servoy is build using Java it can run on any OS with Java support (1.3 and above).

You can download a free (limited number of connections) copy of the server and development environment.

Try it, I've been very happy with it.

Not every project needs to be a masterpiece

[laird]

The person asking the question just wants a simple GUI for a non-engineer to use to build a database. Like, say, FileMaker.

Yes, every database _should_ be designed by someone who really understands database design. But most databases in the real world are running in FileMaker and Access, created by non-engineers in order to keep track of relatively simple information. For example, a call log, or a list of donations to a school, or an inventory at a bookstore. These systems don't need to scale, they just need to be good enough to let people do their jobs. And since they don't _have_ an engineer to do a proper requirements documentation, normalize the design, etc., the options are either (1) a simple GUI tool, and (2) no database.

SQLite is excellent

[GlobalEcho]

I'm a big PostgreSQL fan, but when it came time to do a big project, I ended up with SQLite (and I'm very happy I did).

Basically, the problem was to take a bunch of huge text files, parse them into a set of inputs for a big simulator written in ANSI C, run the simulation, save the results, and postprocess them.

I wrote the parsing in a mixture of Python and SQL (using PySQLite), had the simulator write the results back out the the SQLite database (which was amazingly easy and bug-free), and then did postprocessing again in Python and SQL.

It was WAY easier than my previous attempts to do similar things using embedded Python and/or PostgreSQL. I still love PostgreSQL, but not for this project.