Database Reference
In-Depth Information
so on); the data was stuffed in there, anyway. Part of the reason for this is that, generally
speaking, it's much easier (and more secure) to read and write to a database than it is to
write to a file system. If you pick up any topic that teaches PHP, such as
PHP for Absolute
Beginners,
by Jason Lengstorf (Apress, 2009), you'll probably find that almost right away
the database is used to store information, not the file system. It's just so much easier to
do things that way. And while using a database as a storage bin works, developers always
have to work against the flow. It's usually obvious when we're not using the database the
way it was intended; anyone who has ever tried to store information with even slightly
complex data, had to set up five tables, and then tried to pull it all together knows what
we're talking about!
The MongoDB team decided that it wasn't going to create another database that
tries to do everything for everyone. Instead, the team wanted to create a database
that worked with documents rather than rows and that was blindingly fast, massively
scalable, and easy to use. To do this, the team had to leave some features behind, which
means that MongoDB is not an ideal candidate for certain situations. For example,
its lack of transaction support means that you wouldn't want to use MongoDB to
write an accounting application. That said, MongoDB might be perfect for part of the
aforementioned application (such as storing complex data). That's not a problem, though,
because there is no reason why you can't use a traditional RDBMS for the accounting
components and MongoDB for the document storage. Such hybrid solutions are quite
common, and you can see them in production apps such as the New York Times website.
Once you're comfortable with the idea that MongoDB may not solve all your problems,
you will discover that there are certain problems that MongoDB is a perfect fit for resolving,
such as analytics (think a real-time Google Analytics for your website) and complex data
structures (for example, blog posts and comments). If you're still not convinced that
MongoDB is a serious database tool, feel free to skip ahead to the “Reviewing the Feature
List” section, where you will find an impressive list of features for MongoDB.
■
the lack of transactions and other traditional database features doesn't mean that
MongodB is unstable or that it cannot be used for managing important data.
Note
Another key concept behind MongoDB's design is that there should always be
more than one copy of the database. If a single database should fail, then it can simply
be restored from the other servers. Because MongoDB aims to be as fast as possible, it
takes some shortcuts that make it more difficult to recover from a crash. The developers
believe that most serious crashes are likely to remove an entire computer from service
anyway; this means that even if the database were perfectly restored, it would still not be
usable. Remember: MongoDB does not try to be everything to everyone. But for many
purposes (such as building a web application), MongoDB can be an awesome tool for
implementing your solution.
So now you know where MongoDB is coming from. It's not trying to be the best at
everything, and it readily acknowledges that it's not for everyone. However, for those
who do choose to use it, MongoDB provides a rich document-oriented database that's
optimized for speed and scalability. It can also run nearly anywhere you might want to
run it. MongoDB's website includes downloads for Linux, Mac OS, Windows, and Solaris.
