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?
Re:Every language needs a database. (Score:1, Insightful)
There needs to be an intermediate level. (Score:2)
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. (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
SQLite home address (Score:5, Informative)
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:
Is this the answer? Are there any drawbacks? Anyone have experience with SQLite?
Re:SQLite home address (Score:3, Insightful)
Re:SQLite home address (Score:1)
Re:SQLite home address (Score:2)
SQLite is excellent (Score:3, Informative)
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 postpr
Try this GUI (Score:5, Informative)
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 (Score:2)
Re:Try this GUI (Score:1)
I never saw a better one (including commmercial ones).
Re:Try this GUI (Score:1)
Re:Try this GUI (Score:1)
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!
Lol (Score:2)
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 [mysql.com] 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... (Score:3, Funny)
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... (Score:1)
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 w
Re:If you are not comfortable with database UIs... (Score:3, Insightful)
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*
Easy (Score:4, Insightful)
Re:Easy (Score:1)
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.
Re:Easy (Score:1)
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
GUIs for MySQL (Score:4, Informative)
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
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.
there are plenty of choices (Score:5, Informative)
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.
Re:there are plenty of choices (Score:1)
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 vendo
Re:Intuitive GUI? (Score:3, Insightful)
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 simpl
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.
Re:It's about truth, not tools (Score:4, Insightful)
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 (Score:2)
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 usef
Re:It's about truth, not tools (Score:2)
Having worked with businesses for the last 20 years as a programmer, the only things I can guarante
Not every project needs to be a masterpiece (Score:3, Informative)
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 ne
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
Re:Is there anybody here over 35? (Score:4, Informative)
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.
Re:Is there anybody here over 35? (Score:1)
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:Yes! (Score:2, Insightful)
Re:Yes! (Score:1)
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
Gedafe (Score:4, Informative)
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! (Score:4, Informative)
It's just like Access, except with an multi-window interface instead. It's also extensible with Python.
Re:Yes! (Score:2)
Its an Access like frontend to Pg. Needs Tk.
Re:Yes! (Score:1)
Seems like it's mainly for db admin? Does it do much in the way of input forms/reports?
Re:Yes! (Score:1)
It runs on Mac OS X too!
PgAccess (Score:2)
Re:Is there anybody here over 35? (Score:3, Informative)
It's a shame that Filemaker is only Windows and Mac..
Re:Is there anybody here over 35? (Score:1)
Re:Is there anybody here over 35? (Score:2)
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? (Score:2)
Re:Is there anybody here over 35? (Score:2)
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
Re:Is there anybody here over 35? (Score:2)
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! (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. :)
SQLite? (Score:2)
"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 [slashdot.org]?
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? (Score:2)
Cool! I'll definately have to check that out, sometime.
Re:He could be on to something, here! (Score:1)
DBD::AnyData [cpan.org] 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 (Score:2)
I never tried it, but DataDino Database Explorer should do the trick.
Rekall (Score:2)
The latest version has been released as a free product [totalrekall.co.uk] licensed under the GPL, not without some controversy [slashdot.org].
Re:Rekall (Score:1)
Holy shit that is one of the NASTIEST websites I've ever run across... jesus that is cluttered...
Are you sure? (Score:2)
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
End User Database Applications (Score:2)
i haven't seen one yet... (Score:2)
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 dba
dbm via python (Score:1)
What's So Bloody Difficult About SQL? (Score:2)
Huh? (Score:2)
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,
Rekall (Score:1)
http://www.thekompany.com/products/rekall/
"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. "
phpMyAdmin (Score:2)
If you're really comfortable with xBase... (Score:2)
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 &
Try DBVisualizer, Colorful and powerful (Score:1)
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 (Score:2)
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 datab
Re:Hear me our... FileMaker Pro (Score:2)
Only the server component runs under Linux.
My previous employer experience with dbs. . . (Score:1)
The company I had previously worked for, we did a fair amount of "easy and basic" database manipulation. We had used the Informix db [informix.com] 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 e
DBM is as simple as it gets (Score:2)
PowerBuilder (Score:1)
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 v
Someone really should mention (Score:2)
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. A
Shameless Self Promotion (Score:1)
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 [isqlsf.net] 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, PostgreS
Try Servoy! (Score:2, Informative)
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? (Score:2, Interesting)
Re:What about Berkeley DB? (Score:1)
Here's what you want ... (Score:2)
Nutshell Plus, a/k/a Ultra Plus:
http://www.fairsoft.com/
Still need a better front-end to MySQL (Score:1)
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 com