Matt Butcher

• MongoDB is a stand-alone server
• It is document based, not table-based
• It is schemaless
• You don’t need to learn another query language
• It has great PHP support

Read on to learn a little about each of these.

1. MongoDB is a stand-alone server

Like MySQL or other PostgreSQL, MongoDB listens on a port for incomming connections. It provides tools for querying, creating, updating, and deleting. In theory, you work with it in much the same way that you work with MySQL or PostgreSQL: Connect, perform operations, and close the connection.

2. Goodbye rows and tables, hello documents and collections

Instead of storing data as rows in tables, MongoDB stores entire documents. If a have an piece of ‘article’ data with a title, multiple authors, a body, and tags, the entry is basically going to look like this:

<?php array(   ‘title’ => ‘Hello World’,   ‘authors’ => array(‘John’, ‘Sally’, ‘Jim’),   ‘body’ => ‘Hello world’,   ‘tags’ => array(‘tag1’, ‘tag2’, ‘tag3’) ); ?>

The key thing to notice about the example above is that this one record — this document — is actually stored like a document, and supports things like multiple values for the same field. There is no need to normalize the data into separate tables because, well, there are no tables.

Now, instead of storing documents in a table, they are stored in a collection, which you might think of as something akin to a big list of documents.

3. MongoDB is schemaless

There is no schema language for MongoDB. If you want to create a new document type, you needn’t do anything to tell the database about it beyond simply pushing the new data into the database.

In number2, I mocked up a document. Now if I wanted to define an article type with those fields on it, all I need to do is write the object into the database. What if I decide later to add, say, a date? I just pull the article out of the database, add the date field, and save it.

What about data types? The short answer is that MongoDB uses a type coercion system similar to JavaScript or PHP. That is, the database is effectively weakly typed.

There are a few caveats to that (large chunks of data may need some explicit handling), but for the most part, you can write your MongoDB code like your PHP code.

4. You don’t need to learn another query language!

Remember all of those database abstraction layers you’ve written? Remember all of those ORM layers you’ve worked with? Well you can toss them out. You don’t need them with Mongo.

MongoDB (when using it’s PHP driver) doesn’t have much of a query language. In most cases, you simply give it an array specifying information you want, and it returns you an array of documents.

If you want to run some really sophisticated queries (like Map-Reduce operations), you can pass JavaScript functions into MongoDB, and its internal JavaScript engine can execute the script.

5. PHP and MongoDB are a match made in heaven

PHP already has great MongoDB support. The Mongo driver is available as a PECL extension to PHP, which means that installing it is as easy as running pecl install mongo. (Earlier I wrote a short article detailing the installation process)

From there, you can get started working with Mongo’s API. Complexity-wise, it ranks alongside PDO. It’s not dead-simple, but there should be nothing foreign about it for anyone who has done database development before.

The API documentation (linked above) includes a tutorial and lots of samples, so you should be able to ramp up in a very short period of time. And here’s what you will notice as you go:

• MongoDB is blazingly fast
• Development time is faster, too, since there are no schemas to manage, and very little (if any) data mapping.
• Learning curves are short, because there is no new query language to learn.
• Code is trimmer. After all, you don’t need another ORM, and wrappers are likely to be thin.
• Your code is future-proof. It’s trivially easy to add more fields — even complex fields — to your objects. So as requirements change, you can adapt code quickly.

It took me only one session of MongoDB programming to realize its game-changing potential. That’s what leads me to claim that the new generation of document databases are going to leave SQL-based RDBM systems in the dust — or, more likely, leave them to do what they do well: store data that actually belongs in rows and tables.

http://technosophos.com/node/193