There’s not much in the way of documentation, but the tool is pretty straightforward, and there’s a YouTube video, if you want. To start, just create a new table, giving it a name. The tool will automatically create the autoincremented primary key for each new table. Then you can add other columns and indexes (aka keys). Add more tables as needed, and you can easily indicate the relationships between tables by marking foreign keys. Once you’re done with the design, you can export the SQL. The tool supports many different databases, including MySQL, SQLite, Oracle, and PostgreSQL. The outputted SQL is also nicely broken down, separating, for example, the foreign key statements and table properties (e.g., the character set, collation, and storage engine) into standalone ALTER queries, allowing you to use whatever commands you need when you actually go to create the database in your database application. The generated SQL even provides demo INSERT statements for the tables. Alternatively, you can save the design as XML, allowing you to reload that design in the application for further editing at another time.

I’m always on the lookout for a good database design tool, so was pleased to find this one. It’s particularly useful when I’m not on my primary computer, such as when I’m at a client’s office, and need to whip up some SQL on the fly. Check it out for yourself and see what you think. The price—free—is right!

As for me personally, CouchDB and MongoDB are still most attractive, in some part due to their use of JavaScript and JSON, and in part because of existing PHP libraries for interacting with these database applications.

There are a number of non-relational databases out there; the key ones I’ve come across are MongoDB (I’ve written more about MongoDB separately), Neo4j, Cassandra, and CouchDB (Cassandra and CouchDB are both Apache projects, which is a always a good thing). The benefits of using non-relational databases are most important for sites with a lot of activity and data. And by “a lot”, I mean on a Facebook or near-Facebook level. I believe non-relational databases should be on the Web developer’s radar, but I’m not suggesting we should all jump ship on relational databases just yet; most sites don’t have the performance issues that non-relational database solve and do have the need for data integrity that relational databases offer.

The creators of CouchDB and SQLite have just announced a new query language called UnSQL, for “Unstructured Data Query Language”, pronounced “Uncle”. The hope is that UnQL can do for non-relational databases what SQL did for relational ones: provide a common way of interacting with the underlying database, without too much regard for the database application itself. The project is also being supported by Microsoft, for whatever that’s worth.

For a long discussion of non-relational databases, check out this article at InfoWorld. I also benefited from the posts at Sean Coates’s blog, discussing the initial adoption of CouchDB, and the switch to MongoDB on a project.

MongoDB is an open-source document-oriented database. Instead of storing rows of data in tables, MongoDB stores data as Documents in Collections. Documents are represented using the BSON format, which is extremely similar to JSON (in fact, there’s a strong relationship between MongoDB and JavaScript).

Now this may still sound a lot like the DBMS you’re used to (probably MySQL), but there are big differences here. For starters, and this is a big one, a document-oriented database is not normalized. If you’re storing a Collection of books, every book is a Document in itself. And each Document includes every attribute of that particular book: author, page count, ISBN, publisher information, and so forth. If one book has multiple authors, all of that information goes within that Document. If you want to include the publisher’s information with a book, that goes in the Document, too. This is not a normalized database, where related information is spread out over multiple tables. For many people, including me, this is a pretty foreign concept.

Secondarily, each document in a collection can have different attributes. If one book record has a link to a corresponding Web site, that’s fine. And it’s fine if other documents don’t have that attribute. Crazy, eh?

When it comes time to retrieve stored data, a single “find” command can retrieve a single document, including all its properties, or every document, using any attribute of your choosing to limit the selection. Because the database is not relational, no JOINs are required.

If you’re still thinking that this is snake oil, an argument for using MongoDB can be found on their list of organizations that recently started using it: Shutterfly, Foursquare, bit.ly, Intuit, LexisNexis, SourceForge, GitHub, The New York Times, and more. Those are big names. Now, aside from SourceForge, most aren’t using MongoDB for their primary applications, but they are adopting it in one way or another. If you have the time, on that page are links to several articles and presentations by those companies as to why and how they began using MongoDB.

Now, the MongoDB documentation clearly states there are situations where it’s not an appropriate choice, most specifically applications, such as banking and perhaps e-commerce, that require transactions (as MongoDB does not support transactions). Personally, I always take it as a sign of credibility when companies (or people) admit to their own shortcomings. You would also want to think twice, or three times, before converting an existing RDBMS-based application to MongoDB. The fact that MongoDB does not support SQL means you’d have to change a lot of your existing code to make such a conversion.

Speaking of which, there are drivers for MongoDB in all the popular languages, including my personal favorite, PHP. The MongoDB driver is in PECL and is documented in the PHP manual.

If you want to learn more about MongoDB, I’d recommend the links found on list of organizations that recently started using MongoDB page, plus the following:

• MongoDB and Ecommerce, from the book “MongoDB in Action”.
• A New York Times article on building their product, “Stuffy”, using Ruby on Rails and MondoDB.
• An interview with a data architect at Shutterfly on their decision to use MondoDB.
• An article on how BusinessInsider.com uses MondoDB.
• The WikiPedia list of references on MongoDB

The intention behind MariaDB is to release free and stable, but very similar, alternative to MySQL. The Maria storage engine is a crash-safe version of the MyISAM table type but Maria still doesn’t use transactions (like InnoDB). Version 1.5 of MariaDB is now in beta, with the focus on stability. Version 2 of Maria should include transactions and ACID compliance. Version 2.5 is where the developes intend to really focus on performance. This may seem a little backwards, but it’s much easier to retroactively improve software performance than it is its quality.

• Click Select All under Export to backup every table.
• Check Add DROP TABLE under SQL options > Structure so that the recreation of the database wipes out the existing database (note that you may not always want to do this).
• Check either zipped or gzipped under Save as file. This will automatically check the Save as file box for you.

Once you’ve done this, click on Go. You’ll then be prompted to save the downloaded file to your computer, as you would any file downloaded through a browser. The result is a text file of the SQL commands used to recreate the entire database, from creating the tables to populating them. If you checked a compression type, it’ll be a compressed text file. You can now use this file as a saved backup of your database, edit the commands if needed, or remake the database from it. To do that…

Load the version of phpMyAdmin that’s running on the destination server, for example http://www.example.com/phpMyAdmin. This really must be running behind a restricted area (i.e., requiring authentication to access it), preferably over a secure connection. Then click on the Import link or tab, depending upon what options are presented. Then click the Browse button to select the database backup file (the one already created, now stored on your computer). Then click Go. That’s all there is to it!

This works for me without fail probably 95% of the time. The biggest issue I run across is that the upload limit in the Import tab is 2MB. For large databases, like my forum, one text file—even compressed—is way too large. In such situations, I open up the SQL text file in a text editor, then copy and paste the commands into separate files until they are all under 2MB when compressed. At that point, it’s just a matter of doing multiple imports, one for each file.

As I said, I get asked about this a lot, but it’s really quite simple, thanks to phpMyAdmin. Let me know what questions or comments you may have!