Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Simple Database Interfaces for Unix?

Cliff posted more than 10 years ago | from the hiding-the-complexity dept.

Data Storage 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?

cancel ×


Sorry! There are no comments related to the filter you selected.

Every language needs a database. (0, Insightful)

Futurepower(R) (558542) | more than 10 years ago | (#8132948)

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.

Re:Every language needs a database. (1, Insightful)

Mork29 (682855) | more than 10 years ago | (#8133047)

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.

There needs to be an intermediate level. (1)

Futurepower(R) (558542) | more than 10 years ago | (#8133169)

I believe FoxPro is written in C++. There is nothing about a database that would cause a problem with portability. Okay, so maybe there should be a small database that everyone uses, rather than one for every language.
I don't want to be an administrator of an enterprise-level database just because I want to store error messages in a database. I don't want to subject my users to that. There needs to be an intermediate level. There needs to be an easy interface.

Re:Every language needs a database. (2, Interesting)

jpkunst (612360) | more than 10 years ago | (#8133054)

For what it's worth, PHP 5 will have the SQLite [] embeddable database engine bundled by default. Which means that you won't have to install a separate database engine for lightweight SQL database tasks.


SQLite home address (5, Informative)

Futurepower(R) (558542) | more than 10 years ago | (#8133291)

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:
  • 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 [] than PostgreSQL and MySQL for many common operations.
  • Very simple C/C++ interface [] requires the use of only three functions and one opaque structure.
  • TCL bindings [] included. Bindings for many other languages available separately. []
  • 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 [] . Use for any purpose.

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

Re:SQLite home address (2, Insightful)

Ed Avis (5917) | more than 10 years ago | (#8133992)

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:SQLite home address (0)

Anonymous Coward | more than 10 years ago | (#8134348)

sqlite - as M$ Access - has no constraints (exception is the primary key integer);

Re:SQLite home address (1)

hattmoward (695554) | more than 10 years ago | (#8134460)

I use it with Perl all the time, works beautifully. Very fast, too. If you grow a database greater than 500MB, use the VACUUM verb to shrink it up a bit. As others have mentioned, no type checking, though. Also, the bacula project [] can embed SQLite and use it for its catalog -- I've only used that for testing though, I use a MySQL catalog in production.

Re:SQLite home address (1)

Triumph The Insult C (586706) | more than 10 years ago | (#8140591)

Hatchet [] , a pf log -> html parser, is now using sqlite. fast too. =)

SQLite is excellent (2, Informative)

GlobalEcho (26240) | more than 10 years ago | (#8158824)

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.

Try this GUI (5, Informative)

FlashBuster3000 (319616) | more than 10 years ago | (#8132950)

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? :-)

Re:Try this GUI (1)

FortKnox (169099) | more than 10 years ago | (#8137012)

Wow! THanks for that link (I'm not the author of this ask/., but that's quite a tool... and open source/free!!).

Re:Try this GUI (1)

FlashBuster3000 (319616) | more than 10 years ago | (#8137951)

That's what i thought when i saw this tool the first time.
I never saw a better one (including commmercial ones).

Re:Try this GUI (1)

Aiua (688192) | more than 10 years ago | (#8139016)

Some other good information to know about DBDesigner is that MySQL AB (the company behind MySQL) has purchased and thus secured [] this program's future.

Re:Try this GUI (1)

FlashBuster3000 (319616) | more than 10 years ago | (#8141054)

Hell, yes! Great!
I think this "collaboration" is a great thing.
The best DB-Tool i've ever seen in combination with the best database ;-)
And all free!

If you are not comfortable with database UIs... (-1, Flamebait)

ObviousGuy (578567) | more than 10 years ago | (#8132951)

If you don't understand SQL enough to write it by hand, it may be time to go back to school to learn it.

If someone were to say that they could build Windows applications because they knew how to use the VC++ Resource Editor to create dialogs but didn't feel comfortable writing C++ code, wouldn't you suspect something?

Re:If you are not comfortable with database UIs... (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8133689)

What the fuck is with slashdot nerdlingers and all these stupid fucking analogies?! Do you think it fucking makes you sound smarter?

Jesus fucking christ, just tell him to learn SQL and shut up. Why the fuck would you try to compare it to some random idiot story about a windows C++ blah blah crap crap blah?? Do you fucking think it gets your point across better? Can't you speak English? Then there is no need to make up some fucking story about what its like if it were to happen to someone else in a completely different situation. You only serve to confuse the matter you fuckwit moron anus licking arse puncher.

What you are doing is just like some guy who gets in his car then says no I'll walk to work today, but then he gets in his car anyway and turns on the radio. Then he decides to gas himself so he drives into his garage, closes the door and leaves the motor running.

Does that clear things up for you?

Lol (1)

BoomerSooner (308737) | more than 10 years ago | (#8134006)

In any english writing class they teach you:
Make a statement, then back that statement up. The previous poster was showing that sometimes there is a reason you need more education to implement a database well.

I suggest MySQL Administrator [] when it is completed. Or he could just use MS Access. It teaches you everything the wrong way but you can create a functional piece of shit with it.

Re:If you are not comfortable with database UIs... (2, Funny)

E_elven (600520) | more than 10 years ago | (#8134060)

What is wrong with you slashdot nerdlingerlingers and all these stupid analogies? Do you think it makes you look smarter?

Damn. Just tell him to not use analogies and be quiet. Why would you try to compare it to some random idiot story? Can't you speak without swearing? There is no need to make up some even dumber analogy that is supposed to point out the fallacious logic in the GPs post. You only serve to bring a bad name to all Anonymous Cowards.

If I have a monkey.

Re:If you are not comfortable with database UIs... (0)

Anonymous Coward | more than 10 years ago | (#8134233)

No because he needs the point well beaten into his brain for it to do any good.

And you think I give anonymous cowards a bad name? Are you serious? Compared to the shit some people spew. All I did was to knock some of the stuffing out of a single nerdlinger, and quite possibly bring happiness to many others.

And you shut the hell up about monkeys monkey boy.

Re:If you are not comfortable with database UIs... (0)

Anonymous Coward | more than 10 years ago | (#8134335)

Oh and for the benefit of your impaired brain, and any other half wits who read this, my dumber analogy wasn't to point out any failing of the logic of the post in question. There was no incorrect logic in it, just an idiotic analogy which I was ridiculing.

The analogy wasn't actually one of the worst out there, just the straw that broke the camel's back. There are countless idiots out there typing things about how different CPUs are like cars and trucks and how different operating systems are like this and that, and jesus just cut the crap and stop confusing the matter for crying out loud.

Re:If you are not comfortable with database UIs... (1)

pcmanjon (735165) | more than 10 years ago | (#8143929)

There are countless idiots out there typing things about how different CPUs are like cars and trucks and how different operating systems are like this and that, and jesus just cut the crap and stop confusing the matter for crying out loud.

We make such statements because we're used to idiots who require us to over-simplify it into dumb-nitwit terms in order to grasp tech talk.

My mother for instance, doesn't understand tech terms, so I simplify tech talk into talk she can understand

Maybe if the world was all nerdy then we wouldn't be having this discussion now -- would we?

Re:If you are not comfortable with database UIs... (2, Insightful)

Cecil (37810) | more than 10 years ago | (#8135350)

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.

Easy (3, Insightful)

Mork29 (682855) | more than 10 years ago | (#8132959)

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.

Re:Easy (1)

Enfors (519147) | more than 10 years ago | (#8133044)

It is my impression that this guy wants an application with an underlying database, not just a database. I think he wants an application that allows him to make a database for his CD collection (and stuff like that) using a GUI. Learning MySQL isn't the answer here, because that would also require him to code his appliation himself, which he specifically said he didn't want to.

Re:Easy (2, Interesting)

M1FCJ (586251) | more than 10 years ago | (#8134349)

It is not about learning about a new database. It is learning about ANSI SQL92. Almost all databases under the sun support the main set of functions of SQL92. Even Access out of Office 97 will do.

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.

Re:Easy (1)

Enfors (519147) | more than 10 years ago | (#8134888)

It is not about learning about a new database. It is learning about ANSI SQL92. Almost all databases under the sun support the main set of functions of SQL92. Even Access out of Office 97 will do.

You don't seem to understand what I mean. I think this guy wants nothing to do with any kind of SQL - I think he wants a UNIX GUI application that allows him to make a databases for keeping track of various things, such as his CD collection, and stuff like that. When he has created his database, he wants to be able to push a button that says "Add record", and it'll present a form that allows him to enter the details of one of his CDs (or whatever). He doesn't care which RDBMS is used by this application. He won't ever see any of the code involved, just the GUI.

There are many Palm applications like this, such as SmartList To Go (formerly ThinkDB), HanDBase, MobileDB, etc.

GUIs for MySQL (4, Informative)

Wee (17189) | more than 10 years ago | (#8132974)

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


Re:GUIs for MySQL (0)

Anonymous Coward | more than 10 years ago | (#8141771)

I have been told by a relied source that MySQL AB have pulled the plug on MySQLCC, because it has been too long in developement and progressed very little in this time

TOra (2, Interesting)

twem2 (598638) | more than 10 years ago | (#8133001)

I find TOra [] to be very good.
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.

you SHOULD have to know stuff about databases... (-1, Troll)

cyborch (524661) | more than 10 years ago | (#8133003)

... to use one. See my previous comment [] on the ease of use of computers. If you do not understand the basic principles of a database then maybe you are not the right person to use one. Computers SHOULD be hard to use! Making it hard to use ensures that people who do not know enough don't screw things up for themselves.

That said, the basic principles of databases aren't that hard to learn. You should go buy a book on the subject. Which book is best is a matter of taste, but ask your local tech bookstore clerk for help. They usually are very helpful.

there are plenty of choices (5, Informative)

ajagci (737734) | more than 10 years ago | (#8133016)

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.

Re:there are plenty of choices (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8138130)

Do you really think the Bullshit Comment you just typed in is stored on a filesystem? Go back to school, kid.

Re:there are plenty of choices (0)

Anonymous Coward | more than 10 years ago | (#8139221)

Do you really think the Bullshit Comment you just typed in is stored on a filesystem?

It may not be. But it should be.

Go back to school, kid.

Maybe you should come out here into the real world instead.

Re:there are plenty of choices (1)

Anonymous Coed (8203) | more than 10 years ago | (#8166213)

Hello! Reality check! Of course his comment is stored on a filesystem! Almost all RDBMS systems require an underlying filesystem, and the few that don't essentially implement their own specialized internal version.

CLI (1, Interesting)

jsse (254124) | more than 10 years ago | (#8133034)

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?

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.

Intuitive GUI? (0)

sdukaric (640170) | more than 10 years ago | (#8133061)

Well, SQL syntax itself is intiuitive enough to be useful even for beginners. What more intuitive do you need from "SELECT * FROM mytable;". You CAN read it like a language for simplier usage, but advanced usage is something which makes GUI's obsolete and useless anyway. If you need advanced manipulation of your data, then most certainly you'll do it from within CLI, not GUI.

Re:Intuitive GUI? (2, Insightful)

BenjyD (316700) | more than 10 years ago | (#8133622)

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 [] is meant to be quite good, although I know nothing beyond the post on it.

It's about truth, not tools (5, Interesting)

orthogonal (588627) | more than 10 years ago | (#8133085)

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.

Re:It's about truth, not tools (0)

Anonymous Coward | more than 10 years ago | (#8134745)

Hey dude, the guy needs a GUI, not a lecture from a guy who can't accept a "customer" asking for features. That's the kind of stuff we need to know to make OSS better. Get coding instead of rambling.

Re:It's about truth, not tools (3, Insightful)

Godeke (32895) | more than 10 years ago | (#8135108)

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....

Re:It's about truth, not tools (1)

orthogonal (588627) | more than 10 years ago | (#8139812)

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.

Yeah, he probably is, and yes, he probably can "get away with" it.

And as long as he's the only user, his head will fill in the incomplete parts, he'll mentally catalog exceptions, he'll know what (physical) records are really sub-parts and addenda added to (logical) records when he ran out of space in the main record, etc.

The problem is, if the database turns out to be useful for something, he won't remain the only user. But the new users won't have the extra information the original user carries around in his head.

Eventually the original user will retire or die, and the new users will be left with the gargantuan task of converting his idiolect into a system that works without his intimate involvement. Eventually there will have to be a conversion to a real database, but there will be no algorithms to do the conversion, because the data will be riddles with special exceptions. I've been in these situations, and it's a no-win, because there's no way of knowing what the truth is; the conversion becomes either a series of guesses, or the database designer ends up doing a lot of investigation in the problem domain.

But you're right; if all he's doing is making a Christmas card list, he can get away with using anything.

As far as the MP3 database, please understand I was using it as an example of the complexity lurking in most real things, and I was intentionally eliding the more abstruse qualifications, in order to fit it into a Slashdot post. In doing so, I unintentionally conflated the meaning of "song". I realized this after I posted, but I didn't think it warranted replying to my own post.

I conflated the term "song" by using it to mean both "work or opus" and "title". Basically, my thoughts are similar to yours: there should be (at least) a 1-to-many relationship between a "composition" and a "performance"; the performance is the track so -- implementation detail -- it hold the key of the composition, while the composition has the title of the composition as an attribute. The track also hold the key of the performing artist, or a cardinality reduction table maintains a many-to-many relation between track ("performance") and artists, if we decide we need to represent more than one artist per track -- and in this case we make the cardinality reduction table a "real" table and introduce a "role" attribute that shows what the artist did on the track: sing, play piano, engineer, produce, etc.

CD, album, opus (comprised of several movements), act, opera, cycle of operas, are all ways of arranging a group of tracks in a sequential order; composition-to-track can even be seen a degenerate sequential list usual contain only one element. To what extent these relationships should be individually reified in a table structure, and to what extent different levels in a hierarchy should be represented in single, self-referential table, are judgement calls that are probably better resolved more in terms of implementation efficiency (SQL isn't good at recursive operations, other implementations might be) than any other consideration.

But I think we're mostly in agreement, and I appreciate your insights into the matter.

Re:It's about truth, not tools (1)

Godeke (32895) | more than 10 years ago | (#8144137)

I can understand concern about a project growing beyond its root. I agree completely that if the database turns out to be something useful, then *at that point* (the point other users become involved) it should be expanded and set into at least a third normal form implementation. This is the point that concurrency issues, data lifespans, response time requirements and other hard questions have to be answered.

Having worked with businesses for the last 20 years as a programmer, the only things I can guarantee are: a) change and b) change to your changes.

I see a lot of people get hung up (analysis paralysis) trying to "do the right thing" in even the most throw away projects. My experience has shown that it is far better to throw a prototype or working prototype together in a day or two, and then use it as a launch board for discussion of the real project.

If someone wants a throw away (prototype) database, I would probably build it to third normal, just because it is a habit. It's pretty clear the poster has no idea what third normal is, or how to implement it. Because of that, I also assume many of the other requirements are not covered either. In that case, I wouldn't sweat making a throwaway, since the chances of the project proceeding are probably less than one in four anyway.

If I have taken anything away from working in the business environment for those two decades, it is the emphermal nature of business direction. On the other hand, other fields probably have more stable requirements, and would make the usability of throwaway projects much lower. Ironically, the very "expressing the truth" nature of fifth normal form makes it impractical in the real implementations, because you don't know the truth. (Nor can SQL handle the truth, which is why I find D4 facinating: it can). I have watched people spend weeks gathering requirements for a database, and have softy chuckled knowing that the "prototype" at the end of the week will have *more* changes to fragile structures than my two day bang out job, because the guy who spent a week interviewing people about requirements is so sure he "knows the truth" that he expresses it in a fully formed, rigid structure. My structures are poorly linked, fluid, and after being rejected, are much easier to mallet into the "true truth" than the tightly linked, fully constructed "false truth".

Not every project needs to be a masterpiece (2, Informative)

laird (2705) | more than 10 years ago | (#8155501)

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.

Is there anybody here over 35? (3, Interesting)

JabberWokky (19442) | more than 10 years ago | (#8133113)

There seems to be a great deal of confusion regarding what the fellow is looking for. He's not looking for a easy to use interface, a good GUI, a way to learn SQL, or a simple key/value database (although the latter is closest).

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).


Re:Is there anybody here over 35? (3, Informative)

shyster (245228) | more than 10 years ago | (#8133495)

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 [] 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 [] (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 [] 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 [] 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.

Re:Is there anybody here over 35? (1)

pillohead (553676) | more than 10 years ago | (#8140021)

Openoffice has had great support for database entry since 1.0, check out the trail of Tears: MySQL, ODBC & OpenOffice 1.0 part 1 [] and part 2 [] . The major problem the writer of that article had was all the dependency problems with the various programs. I set it up on a freebsd server no problem, thank god for the ports system.

Yes! (4, Interesting)

Ender Ryan (79406) | more than 10 years ago | (#8133987)

Yes, finally someone else knows what he's talking about!

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:Yes! (2, Insightful)

canadianjoe (692195) | more than 10 years ago | (#8134135)

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:Yes! (1)

GigsVT (208848) | more than 10 years ago | (#8135253)

I do.

Entering data is easy enough, make up the HTML form, tie it to some data validation and an INSERT.

Reports can be pretty time consuming to build in PHP, however. Offsetting this is the fact that you have a full fledged programming language to write reports with, so you can do very fancy things with your reports. Of course you could always use PHP for the entry and something else for the reports if you wanted too.

I also have experience with the terminal based database systems, unfortunately we still have some legacy stuff that was originally on a s36, that represents a lot of our core functions. It's on an s36 emulator now, and the data from it gets imported into the web app nightly.

The main problem with those old systems was a total lack of data validation, and the inflexibility in adding new fields. Maybe more modern versions had more of those features, but ours sucks bad in that regard.

Re:Yes! (0)

Anonymous Coward | more than 10 years ago | (#8138194)

Even very simple "CRUD" (create, remove, update, delete) interfaces are significantly more complicated to do in web applications than with a form builder like MS Access or DBase.

A big part of the problem is the HTML Form model (which doesn't allow declaritive validation), basically forcing one to write javascript. But, there's also the fact that SQL is unavoidable.

I've seen tons of *simple* applications put together over the years by non-programmers using tools like Access, Lotus Notes, dBase, and so on. However, with a Web App, you pretty much need programming skills as a basic cost of entry.

Gedafe (4, Informative)

swusr (689597) | more than 10 years ago | (#8135045)

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

If you're using PostgreSQL [] , Gedafe [] 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! (3, Informative)

iantri (687643) | more than 10 years ago | (#8135392)

Yes. Rekall [] or here for free binaries [] 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:Yes! (1)

dodobh (65811) | more than 10 years ago | (#8138054)

Have you looked for pgaccess?
Its an Access like frontend to Pg. Needs Tk.

Re:Yes! (1)

canadianjoe (692195) | more than 10 years ago | (#8139238)

I've taken a look at the pgaccess website [] .
Seems like it's mainly for db admin? Does it do much in the way of input forms/reports?

Re:Yes! (1)

realkiwi (23584) | more than 10 years ago | (#8143943)

It does.

It runs on Mac OS X too!

PgAccess (1)

dodobh (65811) | more than 10 years ago | (#8149636)

It does do forms, reports and a few more things.

Re:Is there anybody here over 35? (2, Informative)

iantri (687643) | more than 10 years ago | (#8135657)

Sorta like Filemaker [] , 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..

Re:Is there anybody here over 35? (1)

simonfairfax (747042) | more than 10 years ago | (#8136470)

My grandparents use something like that called Q&A. They had such a hard time using under Win2k that they had to hire a DB consultant for around $120/hr. to convert it to MS Access!

Re:Is there anybody here over 35? (1)

ameoba (173803) | more than 10 years ago | (#8137430)

I'm glad I didn't have to write that. While never having used the systems myself, I could tell all the other posters are off base.

As far as the OP is concerned, I don't know of any particular programs that'd help, but searching freshmeat or sourceforge for 'xBase' seems to come up with some relevant looking projects.

Re:Is there anybody here over 35? (1)

LWATCDR (28044) | more than 10 years ago | (#8138831)

Access is probabaly closest to what he wants. There are probabaly 10,000 little and not so little apps that where writen for Dbase, Foxbase, Paradox, and Access. So far the opensource world has produced nothing to really take it's place. Sure a programer could use Perl+DBI and the database of your choice to replace a lot of them but it really is not the same thing.

Re:Is there anybody here over 35? (1)

Evil Pete (73279) | more than 10 years ago | (#8140260)

Ahh memories. I especially liked the self modifying code using the & operator. Yeah, I know evil, shouldn't do it.

I wouldn't call the UI the database though. Certainly there was a default input method that was like that. But when you made custom made screens with SAY etc it wasn't like this ... then you resorted to using db3+ like a real programming language ... with access to C routines and all. It was a cool language, but it was really for relatively small applications. But you could knock up a small app for someone in your lunchtime, literraly ... I know because I did it several times. On the other hand the largest db3 app I wrote was 13,000 lines which is a lot in xbase.

Shouldn't really compared it to SQL though, SQL is meant to scale whereas xbase stuff wasn't.

Re:Is there anybody here over 35? (1)

Pii (1955) | more than 9 years ago | (#8159684)

I think you might be referring to "Clipper," a dBase that I used to use back in the day.

Had a pretty avid fanbase, and from a quick googling, looks like there are people still using it.

He could be on to something, here! (2, Interesting)

tachyonflow (539926) | more than 10 years ago | (#8133162)

Since most posters seem to be trying to force MySQL or PostgreSQL to somehow fit the original poster's needs, I figured I'd reply with my own interpretation of what he wants.

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. :)

SQLite? (1)

Futurepower(R) (558542) | more than 10 years ago | (#8133547)

"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."

I want that, too. Isn't this, from an earlier comment, the answer: SQLite [] ?

The web site says that SQLite is implemented in less than 25K lines of C code, and is faster than MySQL and PostgreSQL for most operations.

Re:SQLite? (1)

tachyonflow (539926) | more than 10 years ago | (#8133727)

I want that, too. Isn't this, from an earlier comment, the answer: SQLite?

Cool! I'll definately have to check that out, sometime.

Re:He could be on to something, here! (1)

rduke15 (721841) | more than 10 years ago | (#8153759)

database-aware Perl CGI scripts without having to use his web host's SQL servers

DBD::AnyData [] sounds like what you're after. A module which allows you use standard Perl DBD database access to non-database sources, like various text files or a even a "database" built in RAM from Perl hashes or arrays, which you can then query with SQL.

DataDino (1)

ggeens (53767) | more than 10 years ago | (#8133613)

I never tried it, but DataDino Database Explorer should do the trick.

Rekall (1)

Earlybird (56426) | more than 10 years ago | (#8134179)

TheKompany's Rekall [] is supposed to be something of a "Microsoft Access for Linux". In other words, GUI-driven database application development: schema, forms, reports, scripting, etc.

The latest version has been released as a free product [] licensed under the GPL, not without some controversy [] .

Re:Rekall (1)

tzanger (1575) | more than 10 years ago | (#8137615)

Holy shit that is one of the NASTIEST websites I've ever run across... jesus that is cluttered...

Re:Rekall (0)

Anonymous Coward | more than 10 years ago | (#8141823)

TheKompany have nothing to do with Rekall. Sometime in November 2003, Rekall returned to its developers. TheKompany are stuck with old versions. If you want to download the most up to date version, please visit for pre-compiled binaries or for the source code

Are you sure? (1)

splattertrousers (35245) | more than 10 years ago | (#8134289)

Are you sure you need a "database"? Can't your store your data in a text file? Or a few text files? Maybe an XML file if you've got a lot of data? Or maybe serialize your objects (i.e., write them all to disk)?

A lot of people here keep suggesting RDBMSs and SQL this and SQL that. I've been using relational databases professionally for about ten years. They are certainly powerful, but I think they're overkill for most applications.

My advice is to start with a flat file, and when your app demands something more, go to a few files. When your app demands even more, think about serialization or XML or something. If you need more power, then go to something like Berkeley DB or some other simple DB. Only when you really really really need something complex should you consider a RDBMS.

End User Database Applications (1) (687626) | more than 10 years ago | (#8134316)

I think what the person who wrote this question is looking for what I would call an End User Database program; programs like FileMaker Pro, dBase, or Access. Client/Server setups like MySQL and PostgreSQL are nice but when all I want to keep an inventory of my comics and CDs, they are overkill and too complicated.

In Soviet Russia... (-1)

I'm not a script, da (638454) | more than 10 years ago | (#8134506)

...database interfaces you!

i haven't seen one yet... (1)

millia (35740) | more than 10 years ago | (#8134539)

having in my earlier days done dbase programming (and then foxpro, before it became part of the Behemoth) i can say that i haven't seen one yet.
i think about the closest i've seen, as stated above, is using Access as a front end.
Access is still too complicated for most untrained users, but it's the best solution in terms of maintaining database quality. you can use excel, but kiss the data quality goodbye...
i'll run through dselect tonight, and see if i see something that's similar.

in some ways, i miss dbase. it was nice and simple, yet could do most all i needed to do relationally. would i go back? not on your life.

i wonder who owns all that old dbase code? strikes me as it wouldn't be outrageously difficult to get it to use mysql, as long as it wasn't coded in assembly.

dbm via python (1)

cryptozoologist (88536) | more than 10 years ago | (#8134953)

with an understanding of only the rudiments of python, you can do a lot pretty easily with the 'anydbm' module. there is nice get-you-started tutorial in the book 'programming python' by mark lutz.

What's So Bloody Difficult About SQL? (1)

John Hasler (414242) | more than 10 years ago | (#8135552)

It took me about half an hour to learn enough SQL to do basic stuff. It isn't that hard.

Huh? (1)

cr0sh (43134) | more than 10 years ago | (#8135905)

Setting up PostgreSQL or MySQL on a *nix box is not that hard. Sure, learning to admin it properly is going to take a little work. However, installing it and getting it running, to the point where you can get playing with SQL, is stupid simple once you read the docs.

I am biased toward PostgreSQL - it offers the true robustness of a real enterprise-level DB - I have no doubt that one day it will beat Oracle at their own game. MySQL is OK for learning on, but I wouldn't use it in any critical application (ie, I wouldn't reccommend it for use in a business environment).

So, install one or the other, fire up psql (or MySQL's equivalent), and start playing with SQL.

A good book to get started with would be O'Reilly's "SQL in a Nutshell" - it will give you the background on SQL and RDBMS theory, and then layout the syntax and use of various SQL for the four major DBMS (MSSQL, Oracle, MySQL, and PostgreSQL), as well as standard SQL (SQL99?). It is probably one of the best books out there.

Sure, it isn't drag-and-drop/clicky like MS Access, etc - yeah, you gotta type. But you will learn a lot, and may even unlearn some bad things you thought were right and correct before (ie, good normalization practices, the need and use for primary keys, etc)...

Rekall (0)

paulywog (114255) | more than 10 years ago | (#8135957)

How about the "Access-Killer" Rekall from TheKompany?

"Rekall is a database front-end. It is not itself a database -- data is stored somewhere else, in an SQL server, and Rekall is fundamentally just a tool to extract, display and update that data (of course, it does lots more than that, it does forms and reports and scripting and so on). It is database agnostic, and does not have any preferred database in the sense that Access(R) uses the Jet(R) database engine. "

Re:Rekall (0)

Anonymous Coward | more than 10 years ago | (#8141757)

Rekall is not longer produced by It was take back by its developers way back in November 2003. The last version have is V2.1.0. Since than Rekall versions have run through V2.1.1, V2.2.0beta0, V2.2.0 beta1, and V2.2.0 beta2

Please visit for pre-compiled binaries
or for the sources

phpMyAdmin (1)

BSDevil (301159) | more than 10 years ago | (#8136351)

For your MySQL needs, what's wrong with phpMyAdmin? It's pretty straightforward, and within half an hour of pulling out some SQL documentation and glancing at how the interface worked, I was fine.

If you're really comfortable with xBase... (1)

shakah (78118) | more than 10 years ago | (#8137950)

*and* you're looking for a programming library, you could always check out CodeBase [] which is xBase-compatible and "...written in ANSI C and C++ and is fully portable between Windows XP, 2000, NT, 9x, CE, 3.x, DOS, OS/2, Macintosh and many UNIX versions, including Linux, BSDI, SCO, UnixWare, AIX, Dec Alpha, Solaris and Sun."

It's no help if you're looking for a UI, though you could always use the API to make simple utils for creating tables & such.

Or, for that matter, create/maintain your tables & indexes in DOS/Windows using dBase/FoxPro/etc. and copy them wherever your app needs to go.

Try DBVisualizer, Colorful and powerful (1)

lonesometrainer (138112) | more than 10 years ago | (#8138878) []

Free (you need to registers), commercial version available($99 i guess).

Ok, this is not really an end-user tool, but an absolutely great DB Frontend. Written in Java, runs on many platforms, very nicely designed and quick.

Java has very solid database drivers these days, as Java (like it or not) has become the main middleware and server-side programming language.

Note to all those java haters out there: try it, you'll like it!

Hear me our... FileMaker Pro (1)

PhunkySchtuff (208108) | more than 10 years ago | (#8140744)

Check out FileMaker Pro [] if you want an easy to use, cross platform and relatively powerful database that I think will do exactly what you want...
It runs on Linux & Mac OS X - so there's your Unix compatibility (it also runs on Windows and Mac OS 9). You can have a database on one machine hosted to other machines over the LAN quite easily, and the power of it is in the simplicity of defining fields and layouts - it's all a GUI based draw, drag and drop interface.
It's a lot more like the old skool databases where you draw a form, fill in the fields and then there's your database, rather than all this new-fangled SQL select * from blah where whatever kind of syntax =)
It is 100% closed source, and you have to pay for it, so two thirds of the people here will immediately dismiss it, but you can download a free trial and see if it does what you want.

Re:Hear me our... FileMaker Pro (1)

gozar (39392) | more than 10 years ago | (#8143892)

Check out FileMaker Pro if you want an easy to use, cross platform and relatively powerful database that I think will do exactly what you want... It runs on Linux & Mac OS X - so there's your Unix compatibility (it also runs on Windows and Mac OS 9).

Only the server component runs under Linux.

My previous employer experience with dbs. . . (1)

MikeDawg (721537) | more than 10 years ago | (#8141137)

The company I had previously worked for, we did a fair amount of "easy and basic" database manipulation. We had used the Informix db [] on our servers at our various sites, and it had a very easy to use text-based (possibly curses, is my guess) front-end. I don't remember the front-end having any other names, and I don't personally use informix, so I don't know if the front-end ships standard with informix or not?

I can't say the front-end was the most powerful thing in the world, but for our needs, it got everything done for us. . . After doing a little snooping around with it, it seems like it has a lot of functions that any basic - mid level user would need in order to manipulate a database.

DBM is as simple as it gets (1)

deek (22697) | more than 10 years ago | (#8141397)

It's available from GNU [] , it can be used with C programs [] , Perl scripts [] , PHP, Python, etc. It's databasing at its simplest. I use it myself. It works well.

PowerBuilder (1)

wimbor (302967) | more than 10 years ago | (#8143142)


Sybase has a database application programming system called PowerBuilder. It uses compiled programs, datawindows and relies heavily on SQL scripting. Although I'm not very fond of the application programming part of the system, I do like the simple SQL editor that is included with it. It can connect to all databases (with plugins) and ODBC sources. Features a very nice 'white blank page' SQL editor screen that highlights key SQL keywords (a bit like the IDE of VisualBasic) and offers very easy data viewing and manipulation.

I tried products like TOAD and Aqua Data Studio, but found these to be very restrictive and a lot more difficult for easy queries and result editing. I do not recommend it here for you, but is there anybody out there that knows about an SQL editor that can connect to all these databases and is as simple, yet more powerfull than PowerBuilder? (And features Unicode support :-) ?)

WINE, VFP5 or VFP6 (0)

Anonymous Coward | more than 10 years ago | (#8143394)

I know this is a little late, but it is exactly what you asked for. Visual Foxpro is the descendent of Foxpro, a Dbase3 /Clipper clone. It runs quite well under Wine without much setup. Note that that VFP5 & VFP 6 are not anti-licensed like the later versions (restricted by MS from being used on Linux). I use VFP5 all the time under WINE. There are articles on the web on how to make VFP run under wine. Obviously, the apps will run under MS & Linux & if you have the right compilers, Macs.

Someone really should mention (1)

Rysc (136391) | more than 10 years ago | (#8143591)


I don't know where to get it, other than apt-get install gaby. It's a VERY light database-type thing without an actual database. It's perfect for organizing small amounts of relatively simple information, like a comic book collection, or names and addresses.

What's more, it's GUI and can be installed easily right now. No need for any learning at all.

It's way, way too simple for most uses, but this guy doesn't want a relational database, he wants a laymans Database, which s just the storage of data. And gaby does that perfectly.

From the control file description:

Gaby is a _small_ personal databases manager for Linux
using GTK+ and Gnome for its GUI.
It was designed to provide straight-forward access to databases
a 'normal' user would like (addresses, books, ...) while keeping
the ability to easily create databases for other needs. On a
technical side it was designed with extensibility in mind and
thus use relies a lot on plug-ins.

Shameless Self Promotion (1)

FooMasterZero (515781) | more than 10 years ago | (#8143890)

I have been writing a tool to address this issue, even though most DBA's will not use GUI's more than just DBA's need to interact with the database as well.

I have written an application called iSQL-Viewer [] The basic premisie is to take advantage of Java and JDBC. At this point there is nothing platform specific in the application and it is mainly designed with developers in mind to easily view and load data in a given database.

I have used it against Sybase, MSSQL, Oracle, PostgreSQL, and MySQL and it has been known to work on various other platforms including SQLite, and Informix

Try Servoy! (2, Informative)

dso (9793) | more than 10 years ago | (#8145050)

There's an excellent program called Servoy ( 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.

What about Berkeley DB? (2, Interesting)

broody (171983) | more than 10 years ago | (#8146003)

What about Berkeley DB? Sleepycat [] makes a simple "database" that sounds exactly like what the poster is looking for in a database.

Re:What about Berkeley DB? (1)

FPCat (646737) | more than 10 years ago | (#8176424)

This DB does rock. It's small, reliable, simple to learn. Recommended if you need a simple key/value storage system

Here's what you want ... (1)

nbvb (32836) | more than 10 years ago | (#8158593)

A simple database that works REALLY well?

Nutshell Plus, a/k/a Ultra Plus:

Still need a better front-end to MySQL (1)

managerialslime (739286) | more than 9 years ago | (#8162466)

Many of the replies to this post make my head throb. Why? I've got a similar requirement and have been searching for the solution, and am praying for some kind soul to share a solution with us. Instead, there is a bunch of people with answers that avoid (evade?) the poster's request.

In the olden days, I could use a user-friendly cheap commercial product to drop a small app on the desk of a non-techie who could do REAL WORK with MINIMAL subsequent support required from me.

The user friendly cheap commercial product?: Mostly Q&A, PFSfile, AlphaFour, and FileMaker Pro.

What did a typical app include?:

- a data entry form with field level validation and external table lookups on every field, including drop-down menus.
- If/then/else logic based on field entries for data manipulation and jumping to other form fields
- a couple of dozen canned queries with totals and sub totals, counts, averages, min and max values
- Indexing of any or all fields
- Tables could hold 100,000 records with fast searching and report generation
- Importing of dBase, spreadsheet, column-delimited or tab-delimited data files, including field and record-level error checking.
- Intelligent handling of a kazillion date formats and date logic
- Most of the field-types found today in MS-Access including MEMO
- Both record (form) and table (similar to spreadsheet) views
- Password protection
- trigger-type updating to external tables
- trigger-type lookups from external tables
- Custom menus

Now here is the kicker (listen closely campers): Absolutely everything in the application could be MAINTAINED or ENHANCED by BTEUs (BARELY-TECHNICAL-END-USERS).

In other words, with a single one-hour class, I could teach darn near anyone to use the app. EVEN MORE IMPORTANTLY: with between two and four hour sessions, I could teach a BTEU to add fields, logic, reports, ad hoc extracts, and lookup tables.

Today, I have PHP and MYSQL for the small apps my team creates for our BTEUs. What w need is a Q&A-type front-end to MYSQL so give to users so they can do EVERYTHING in the list three paragraphs above.

Don't worry about the apps getting too big or too complex. 99% will have less than 10 tables of less than 10,000 records per table. The 1% of applications whose requirements balloon into ten of millions of records we re-write from scratch in Perl/Oracle or PHP/Perl/Oracle or ColdFusion/Perl/Oracle anyway.

Today, MS-Access enables the BTEU to quickly get in trouble and generate support calls that exceed number of intelligent support hours available in the universe across all dimensions from now until eternity. Most "friendlier" approaches are too complex to enable the BTEU to do their own application maintenance.

Based on the comments thus far, I will be researching:

- -- - - pgaccess - - for pre-compiled binaries - for the sources

I pray for some words-of-wisdom. Not let-it-be.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>