Database Reference
In-Depth Information
Chapter 1
Introduction to MongoDB
Imagine a world where using a database is so simple that you soon forget you're even using it. Imagine a world where
speed and scalability
just work
, and there's no need for complicated configuration or setup. Imagine being able to
focus only on the task at hand, get things done, and then—just for a change—leave work on time. That might sound
a bit fanciful, but MongoDB promises to help you accomplish all these things (and more).
MongoDB (derived from the word
humongous
) is a relatively new breed of database that has no concept of
tables, schemas, SQL, or rows. It doesn't have transactions, ACID compliance, joins, foreign keys, or many of the
other features that tend to cause headaches in the early hours of the morning. In short, MongoDB is a very different
database than you're probably used to, especially if you've used a relational database management system (RDBMS)
in the past. In fact, you might even be shaking your head in wonder at the lack of so-called “standard” features.
Fear not! In the following pages, you will learn about MongoDB's background and guiding principles, and why
the MongoDB team made the design decisions that it did. We'll also take a whistle-stop tour of MongoDB's feature list,
providing just enough detail to ensure that you'll be completely hooked on this topic for the rest of the topic.
We'll start by looking at the philosophy and ideas behind the creation of MongoDB, as well as some of the
interesting and somewhat controversial design decisions. We'll explore the concept of document-oriented databases,
how they fit together, and what their strengths and weaknesses are. We'll also explore JSON and examine how it
applies to MongoDB. To wrap things up, we'll step through some of the notable features of MongoDB.
Reviewing the MongoDB Philosophy
Like all projects, MongoDB has a set of design philosophies that help guide its development. In this section, we'll
review some of the database's founding principles.
Using the Right Tool for the Right Job
The most important of the philosophies that underpin MongoDB is the notion that
one size does not fit all
. For many
years, traditional relational (SQL) databases (MongoDB is a document-oriented database) have been used for storing
content of all types. It didn't matter whether the data was a good fit for the relational model (which is used in all
RDBMS databases, such as MySQL, PostgresSQL, SQLite, Oracle, MS SQL Server, and 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!
