CouchDB and PHP Web Development Beginner's Guide - Tim Juravich - E-Book

CouchDB and PHP Web Development Beginner's Guide E-Book

Tim Juravich

0,0
34,79 €

-100%
Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.

Mehr erfahren.
Beschreibung

CouchDB is a NoSQL database which is making waves in the development world. It's the tool of choice for many PHP developers so they need to understand the robust features of CouchDB and the tools that are available to them.CouchDB and PHP Web Development Beginner's Guide will teach you the basics and fundamentals of using CouchDB within a project. You will learn how to build an application from beginning to end, learning the difference between the "quick way"ù to do things, and the "right way"ù by looking through a variety of code examples and real world scenarios. You will start with a walkthrough of setting up a sound development environment and then learn to create a variety of documents manually and programmatically. You will also learn how to manage their source control with Git and keep track of their progress. With each new concept, such as adding users and posts to your application, the author will take you through code step-by-step and explain how to use CouchDB's robust features. Finally, you will learn how to easily deploy your application and how to use simple replication to scale your application.

Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:

EPUB
MOBI

Seitenzahl: 323

Veröffentlichungsjahr: 2012

Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Table of Contents

CouchDB and PHP Web Development Beginner's Guide
Credits
About the Author
About the Reviewers
www.PacktPub.com
Support files, eBooks, discount offers and more
Why Subscribe?
Free Access for Packt account holders
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Time for action — heading
What just happened?
Pop quiz — heading
Have a go hero — heading
Reader feedback
Customer support
Downloading the example code
Errata
Piracy
Questions
1. Introduction to CouchDB
The NoSQL database evolution
What makes NoSQL different
Classification of NoSQL databases
CAP theorem
ACID
So what does all of that mean?
Advantages of NoSQL databases
Negatives of NoSQL databases
When you should use NoSQL databases
When you should avoid NoSQL databases
Introduction to CouchDB
The history of CouchDB
Defining CouchDB
Summary
2. Setting up your Development Environment
Operating systems
Windows
Installing Apache and PHP
Installing Git
Installing CouchDB
Linux
Installing Apache and PHP
Installing Git
Installing CouchDB
Setting up your web development environment on Mac OS X
Terminal
Time for action — using Terminal to show hidden files
What just happened?
Text editor
Apache
Web browser
Time for action — opening your web browser
What just happened?
PHP
Time for action — checking your PHP version
What just happened?
Time for action — making sure that Apache can connect to PHP
What just happened?
Time for action — creating a quick info page
What just happened?
Fine tuning Apache
Time for action — further configuration of Apache
What just happened?
Our web development setup is complete!
Installing CouchDB
Homebrew
Time for action — installing Homebrew
What just happened?
Time for action — installing CouchDB
What just happened?
Checking that our setup is complete
Starting CouchDB
Time for action — checking that CouchDB is running
What just happened?
Running CouchDB as a background process
Installing version control
Git
Time for action — installing and configuring Git
What just happened?
Did you have any problems?
Pop quiz
Summary
3. Getting Started with CouchDB and Futon
What is CouchDB?
Database server
Documents
Example of a CouchDB document
JSON format
Key-value storage
Reserved fields
RESTful JSON API
Time for action — getting a list of all databases in CouchDB
What just happened?
Time for action — creating new databases in CouchDB
What just happened?
Time for action — deleting a database In CouchDB
What just happened?
Time for action — creating a CouchDB document
What just happened?
Futon
Time for action — updating a document in Futon
What just happened?
Time for action — creating a document in Futon
What just happened?
Security
Time for action — taking CouchDB out of Admin Party
What just happened?
Time for action — anonymously accessing the _users database
What just happened?
Time for action — securing the _users database
What just happened?
Time for action — checking to make sure the database is secure
What just happened?
Time for action — accessing a database with security enabled
What just happened?
Pop quiz
Summary
4. Starting your Application
What we'll build in this book
Bones
Project setup
Time for action — creating the directories for Verge
What just happened?
Source control with Git
Time for action — initializing a Git repository
What just happened?
Implementing basic routing
Time for action — creating our first file: index.php
What just happened?
.htaccess files
Time for action — creating the .htaccess file
What just happened?
Hacking together URLs
Creating the skeleton of Bones
Time for action — hooking up our application to Bones
What just happened?
Using Bones to handle requests
Time for action — creating the class structure of Bones
What just happened?
Accessing the route
Time for action — creating functions to access the route on Bones creation
What just happened?
Matching URLs
Time for action — creating the register function to match routes
What just happened?
Calling the register function from our application
Time for action — creating a get function in our Bones class
What just happened?
Adding routes to our application
Time for action — creating routes for us to test against Bones
What just happened?
Testing it out!
Adding changes to Git
Handling layouts and views
Using Bones to support views and layouts
Time for action — using constants to get the location of the working directory
What just happened?
Time for action — allowing Bones to store variables and the content path
What just happened?
Time for action — allowing our application to display a view by calling it in index.php
What just happened?
Time for action — creating a simple layout file
What just happened?
Adding views to our application
Time for action — rendering views inside of our routes
What just happened?
Time for action — creating views
What just happened?
Adding changes to Git
Adding support for other HTTP methods
Time for action — retrieving the HTTP method used in a request
What just happened?
Time for action — altering the register to support different methods
What just happened?
Time for action — adding simple but powerful helpers to Bones
What just happened?
Using a form to test our HTTP method support
Testing it out!
Adding changes to Git
Adding support for complex routing
Handling complex routes
Accessing route variables
Adding more complex routes to index.php
Testing it out!
Adding changes to Git
Adding support for public files
Time for action — altering .htaccess to support public files
What just happened?
Time for action — creating a stylesheet for the application
What just happened?
Adding changes to Git
Publishing your code to GitHub
Get complete code from GitHub
Summary
5. Connecting your Application to CouchDB
Before we get started
Time for action — creating a database for Verge with curl
What just happened?
Diving in head first
Adding logic to our signup script
Time for action — adding an e-mail field to the signup form
What just happened?
Using curl calls to post data to CouchDB
Time for action — creating a standard object to encode to JSON
What just happened?
Committing it to Git
Time for action — creating a CouchDB document with PHP and curl
What just happened?
Committing it to Git
Is this technique good enough?
Available CouchDB libraries
Sag
Downloading and setting up Sag
Time for action — using Git to install Sag
What just happened?
Adding Sag to Bones
Time for action — adding Sag to Bones
What just happened?
Simplifying our code with Sag
Time for action — creating a document with Sag
What just happened?
Adding more structure
Time for action — including the classes directory
What just happened?
Working with classes
Time for action — creating a Base object
What just happened?
Time for action — creating a User object
What just happened?
Time for action — plugging the User object in
What just happened?
Testing it out
Committing it to Git
Wrapping up
Summary
6. Modeling Users
Before we get started
Cleaning up our interface by installing Bootstrap
Time for action — installing Bootstrap locally
What just happened?
Time for action — including Bootstrap and adjusting our layout to work with it
What just happened?
Time for action — sprucing up the home page
What just happened?
Moving all user files into the user folder
Time for action — organizing our user views
What just happened?
Designing our user documents
How CouchDB looks at basic user documents
Adding more fields to the user document
Discussing options for adding these fields
Adding support for the additional fields
Time for action — adding the fields to support the user documents
What just happened?
The signup process
A little administrator setup
Updating the interface
Quick and dirty signup
Time for action — handling simple user signup
What just happened?
SHA-1
Testing the signup process again
Refactoring the signup process
Time for action — cleaning up the signup process
What just happened?
Exception handling and resolving errors
Deciphering error logs
Time for action — examining Apache's log
What just happened?
Time for action : Examine CouchDB's log
What just happened?
Catching errors
Time for action — handling document update conflicts using SagCouchException
What just happened?
Showing alerts
Time for action — showing alerts
What just happened?
User authentication
Setting up for the login form
Have a go hero — setting up the routes and forms for login
Logging in and logging out
Time for action — adding functionality for users to log in
What just happened?
Time for action – adding functionality for users to log out
What just happened?
Handling the current user
Time for action – handling the current user
What just happened?
Summary
7. User Profiles and Modeling Posts
User profile
Finding a user with routes
Time for action — getting single user documents
What just happened?
Time for action — creating a route for user profiles
What just happened?
Time for action — creating the user profile
What just happened?
Testing it out
Adding your changes to Git
Fixing some problems
Finding errors
Time for action — examining Apache's log
What just happened?
Handling 500 errors
Time for action — handling 500 errors with Bones
What just happened?
Time for action — handling exceptions
What just happened?
Testing our exception handler
Showing 404 errors
404 if user isn't found
Time for action : handling 404 errors with Bones
What just happened?
Showing 404 errors for unknown users
Hooking up 404 all around the site
Time for action — handling 404 errors with Bones
What just happened?
Testing it out
Giving users a link to their profile
Creating a better profile with Bootstrap
Time for action — checking whether a user is currently logged in
What just happened?
Cleaning up the profile's design
Let's check out our new profile
Adding your changes to Git
Posts
Modeling Posts
How to model posts in MySQL
How to model posts in CouchDB
Have a go hero — setting up the Post class
Creating posts
Time for action — making a function to handle Post creation
What just happened?
Time for action — making a form to enable Post creation
What just happened?
Time for action — creating a route and handling the creation of the Post
What just happened?
Test it out
Adding your changes to Git
Wrapping up
Summary
8. Using Design Documents for Views and Validation
Design documents
A basic design document
Views
Map functions
Time for action — creating a temporary view
What just happened?
Time for action — creating a view for listing posts
What just happened?
Querying map functions
Time for action — querying the posts_by_user view
What just happened?
Using the view in our application
Time for action — adding support to get_posts_by_user in the post class
What just happened?
Time for action — adding posts to the user profile
What just happened?
Reduce functions
Time for action — creating the reduce function in Futon
What just happened?
Time for action — adding support to our application to consume the reduce function
What just happened?
More with MapReduce
Validation
Time for action — adding support for $_rev to our classes
What just happened?
Time for action — adding support to delete posts in our application
What just happened?
CouchDB's support for validation
Time for action — adding a validate function to ensure that only creators can update or delete their documents
What just happened?
Time for action – hiding the delete buttons when not on the current user's profile
What just happened?
Wrapping up
Want more examples?
Working with design documents in Futon is too hard!
Summary
9. Adding Bells and Whistles to your Application
Adding jQuery to our project
Installing jQuery
Time for action — adding jQuery to our project
What just happened?
Time for action — creating master.js and connecting Boostrap's JavaScript files
What just happened?
Using jQuery to improve our site
Fixing our delete post action to actually use HTTP delete
Time for action — improving our user experience by using AJAX to delete posts
What just happened?
Updating our route to use the DELETE HTTP method
Let's test it out!
Adding simple pagination using jQuery
Time for action — taking posts out of profile.php and putting them in their own partial view
What just happened?
Adding backend support for pagination
Time for action — adjusting our get_posts_by_user function to skip and limit posts
What just happened?
Let's test it out!
Time for action — refactoring our code so it's not redundant
What just happened?
Time for action — adding frontend support for pagination
What just happened?
Time for action — fixing our delete post function to work with pagination
What just happened?
Testing our complete pagination system
Using Gravatars
Time for action — adding Gravatars to our application
What just happened?
Testing our Gravatars
Adding everything to Git
Summary
10. Deploying your Application
Before we get started
Application hosting
CouchDB hosting
Database hosting with Cloudant
Getting started with Cloudant
Creating a _users database
Creating a verge database
Have a go hero — give it a shot yourself
Using Futon on Cloudant
Configuring permissions
Configuring our project
Time for action — creating a configuration class
What just happened?
Time for action — adding our configuration file to Bones
What just happened?
Adding changes to Git
Application hosting with PHP Fog
Setting up a PHP Fog account
Creating environment variables
Deploying to PHP Fog
Adding our SSH key to PHP Fog
Connecting to PHP Fog's Git repository
Get the repository from Php Fog
Connecting to the repository from Git
Deploy to PHP Fog
Replicating local data to production
Time for action — replicating our local _users database to Cloudant
What just happened?
Have a go hero — replicating the local verge database to Cloudant
What's next?
Scaling your application
Next steps
Summary
A. Pop quiz — Answers
Chapter 2, Setting up your Development Environment
Chapter 3, Getting Started with CouchDB and Futon
Index

CouchDB and PHP Web Development Beginner's Guide

CouchDB and PHP Web Development Beginner's Guide

Copyright © 2012 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

First published: June 2012

Production Reference: 1150612

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham B3 2PB, UK.

ISBN 978-1-849513-58-6

www.packtpub.com

Cover Image by Parag Kadam ( <[email protected]> )

Credits

Author

Tim Juravich

Reviewers

Gonzalo Ayuso

David Carr

Wenbert Del Rosario

Acquisition Editor

Sarah Cullington

Lead Technical Editors

Arun Nadar

Chris Rodrigues

Technical Editor

Lubna Shaikh

Project Coordinator

Leena Purkait

Proofreader

Kevin McGowan

Indexer

Monica Ajmera Mehta

Graphics

Manu Joseph

Valentina D'silva

Production Coordinator

Arvindkumar Gupta

Cover Work

Arvindkumar Gupta

About the Author

Tim Juravich is an experienced product, program, and technology leader who has spent the past decade leading teams through a variety of projects in PHP, Ruby, and .NET. After gaining experience at several Fortune 500 companies, Tim discovered entrepreneurship, founded three of his own startups, and helped dozens of other startups open their doors.

Tim currently serves as the Director of Program Management for Thinktiv, a venture accelerator. When not at work, Tim actively mentors engineers, contributes to open source projects, and works on a variety of side projects.

Check out Tim's blog at http://juravich.com, and be sure to follow him on Twitter @timjuravich

I would like to thank my loving parents, my older (but smaller) brother Jon, and my wife Leigha. Without Leigha's support and love through our first year of marriage, this book, and much more, would not have been possible.

I would also like to thank my clients and colleagues who have provided invaluable opportunities for me to shape my career, my life, and my perspective on technology.

About the Reviewers

Gonzalo Ayuso is a web architect with more than 10 years of experience in web development, specializing in open source technologies. He has experience in delivering scalable, secure, and high-performing web solutions to large scale enterprise clients. He has a varied background, always related to Linux and the Internet. He is mainly focused on Internet technologies, databases, and programming languages (mostly PHP, Python, and JavaScript). You can check his blog at gonzalo123.wordpress.com or follow him on Twitter @gonzalo123.

Wenbert Del Rosario is from Cebu, Philippines. He started his career as a web developer in college, learning PHP and Adobe Photoshop. He works with open source technologies — Zend Framework, Code Igniter, MySQL, jQuery, and Wordpress are some of the tools he has up his sleeve. He also works with Django (Python) and Ruby on Rails.

In his free time, he loves to work on personal projects. He also does some freelance and consulting. He knows he has a lot to learn, but his experience has taught him to solve real-world and business problems. He is very passionate and shares some of his thoughts and day-to-day encounters through his blog (http://blog.ekini.net).

Wenbert's latest employer is Norwegian Pacific Offshore. He also has worked for Lexmark Research and Development Corporation in Cebu.

I would like to thank my family and my wife, Noeme, for all their support and encouragement.

www.PacktPub.com

Support files, eBooks, discount offers and more

You might want to visit www.PacktPub.com for support files and downloads related to your book.

Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.

At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.

http://PacktLib.PacktPub.com

Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can access, read and search across Packt's entire library of books.

Why Subscribe?

Fully searchable across every book published by PacktCopy and paste, print and bookmark contentOn demand and accessible via web browser

Free Access for Packt account holders

If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view nine entirely free books. Simply use your login credentials for immediate access.

Preface

PHP and CouchDB Web Development will teach you the fundamentals of combining CouchDB and PHP to create a full application from conception to deployment. This book will direct you in developing a basic social network, while guiding you through some of the common pitfalls that are frequently associated with NoSQL databases.

What this book covers

Chapter 1, Introduction to CouchDB, provides a quick definition of NoSQL and an overview of CouchDB.

Chapter 2, Setting up your Development Environment, sets up your computer for developing an application with PHP and CouchDB.

Chapter 3, Getting Started with CouchDB and Futon, defines CouchDB documents and shows how to manage them both from the command-line and within Futon — CouchDB's built-in administration utility.

Chapter 4, Starting your Application, creates a simple PHP framework to house your application and publishes this code to GitHub.

Chapter 5, Connecting your Application to CouchDB, connects your application to CouchDB using a variety of methods, and ultimately picks the right solution for your application.

Chapter 6, Modeling Users, creates users within your application and handles document creation and authentication with CouchDB.

Chapter 7, User Profiles and Modeling Posts, perfects your user profile using Bootstrap and posts content to CouchDB.

Chapter 8, Using Design Documents for Views and Validation, explores CouchDB's exclusive use of Design Documents to improve the quality of your application.

Chapter 9, Adding Bells and Whistles to your Application, leverages existing tools to simplify and improve your application.

Chapter 10, Deploying your Application, shows your application to the world, and teaches you how to launch your application and database using a variety of Cloud services.

Bonus Chapter, Replicating your Data, finds out how to use CouchDB's replication system to scale your application as it grows.

You can download the Bonus Chapter from http://www.packtpub.com/sites/default/files/downloads/Replicating_your_Data.pdf.

What you need for this book

You'll need a modern computer with Mac OSX. Chapter 1, Introduction to CouchDB, will provide the setup instructions for Linux and Windows machines, and the code written in this book will work on any machine. However, the majority of the command-line statements and applications that we'll use in this book are Mac OSX-specific.

Who this book is for

This book is for beginners and intermediate PHP developers, who are interested in using CouchDB development in their projects. Advanced PHP developers will appreciate the familiarity of the PHP architecture, and can easily learn how to incorporate CouchDB into their existing development experiences.

Conventions

In this book, you will find several headings appearing frequently.

To give clear instructions of how to complete a procedure or task, we use:

Time for action — heading

Action 1Action 2Action 3

Instructions often need some extra explanation so that they make sense, so they are followed with:

What just happened?

This heading explains the working of tasks or instructions that you have just completed.

You will also find some other learning aids in the book, including:

Pop quiz — heading

These are short multiple choice questions intended to help you test your own understanding.

Have a go hero — heading

These set practical challenges and give you ideas for experimenting with what you have learned.

You will also find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.

Code words in text are shown as follows: " It's difficult to standardize the install methods for Linux, because there are many different flavors and configurations."

A block of code is set as follows:

<Directory /> Options FollowSymLinks AllowOverride None Order deny,allow Allow from all </Directory>

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

<Directory /> Options FollowSymLinks AllowOverride All Order deny,allow Allow from all </Directory>

Any command-line input or output is written as follows:

sudo apt-get install php5 php5-dev libapache2-mod-php5 php5-curl php5-mcrypt

New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this:"Start by opening Terminal".

Note

Warnings or important notes appear in a box like this.

Tip

Tips and tricks appear like this.

Reader feedback

Feedback from our readers is always welcome. Let us know what you think about this book — what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.

To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title through the subject of your message.

If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.

Customer support

Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.

Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

Errata

Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books — maybe a mistake in the text or the code — we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the errata submission form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website, or added to any list of existing errata, under the Errata section of that title.

Piracy

Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.

Please contact us at <[email protected]> with a link to the suspected pirated material.

We appreciate your help in protecting our authors, and our ability to bring you valuable content.

Questions

You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.

Chapter 1. Introduction to CouchDB

Welcome to CouchDB and PHP Web Development Beginner's Guide. In this book, we will learn the ins and outs of building a simple but powerful website using CouchDB and PHP. For you to understand why we do certain things in CouchDB, it's first important for you to understand the history of NoSQL databases and learn CouchDB's place in database history.

In this chapter we will:

Go over a brief history of databases and their place in technologyTalk about how databases evolved into the concept of NoSQLDefine NoSQL databases by understanding different classifications of NoSQL databases, the CAP theorem and its avoidance of the ACID modelLook at the history of CouchDB and its main contributorsTalk about what makes CouchDB special

Let's start by looking at the evolution of databases and how NoSQL arrived on the scene.

The NoSQL database evolution

In the early 1960s, the term database was introduced to the world as a simple layer that would serve as the backbone behind information systems. The simple concept of separating applications from data was new and exciting, and it opened up possibilities for applications to become more robust. At this point, databases existed first as tape-based devices, but soon became more usable as system direct-access storage on disks.

In 1970, Edgar Codd proposed a more efficient way of storing data — the relational model. This model would also use SQL to allow the applications to find the data stored within its tables. This relational model is nearly identical to what we know as traditional relational databases today. While this model was widely accepted, it wasn't until the mid 1980s that there was hardware that could actually make effective use of it. By 1990, hardware finally caught up, and the relational model became the dominant method for storing data.

Just as in any area of technology, competition arose with Relational Database Management Systems (RDBMS) . Some examples of popular RDMBS systems are Oracle, Microsoft SQL Server, MySQL, and PostgreSQL.

As we moved past the year 2000, applications began to produce incredible amounts of data through more complex applications. Social networks entered the scene. Companies wanted to make sense of the vast amounts of data that were available. This shift brought up some serious concerns about the datastructure, scalability, and availability of data that the relational model didn't seem to handle. With the uncertainty of how to manage this large amount of ever-changing data, the term NoSQL emerged.

The term NoSQL isn't short for "no SQL;" it actually stands for "not only SQL". NoSQL databases are a group of persistent solutions, which do not follow the relational model and do not use SQL for querying. On top of that, NoSQL wasn't introduced to replace relational databases. It was introduced to complement relational databases where they fell short.

What makes NoSQL different

Besides the fact that NoSQL databases do not use SQL to query data, there are a few key characteristics of NoSQL databases. In order to understand these characteristics, we'll need to cover a lot of terminology and definitions. It's not important that you memorize or remember everything here, but it's important for you to know exactly what makes up a NoSQL database.

The first thing that makes NoSQL databases different is their data structure. There are a variety of different ways in which NoSQL databases are classified.

Classification of NoSQL databases

NoSQL databases (for the most part) fit into four main data structures:

Key-value stores: They save data with a unique key and a value. Their simplicity allow them to be incredibly fast and scale to enormous sizes.Column stores: They are similar to relational databases, but instead of storing records, they store all of the values for a column together in a stream.Document stores: They save data without it being structured in a schema, with buckets of key-value pairs inside a self-contained object. This datastructure is reminiscent of an associative array in PHP. This is where CouchDB lands on the playing field. We'll go much deeper into this topic in Chapter 3, Getting Started with CouchDB and Futon.Graph databases: They store data in a flexible graph model that contains a node for each object. Nodes have properties and relationships to other nodes.

We won't go too deeply into examples of each of these types of databases, but it's important to look at the different options that are out there. By looking at databases at this level, it's relatively easy for us to see (in general) how the data will scale to size and complexity, by looking at the following screenshot:

If you look at this diagram, you'll see that I've placed a Typical Relational Database with a crude performance line. This performance line gives you a simple idea of how a database might scale in size and complexity. How is it possible that NoSQL databases perform so much better in regards to high size and complexity of data?

For the most part, NoSQL databases are scalable because they rely on distributed systems and ignore the ACID model. Let's talk through what we gain and what we give up through a distributed system, and then define the ACID model.

When talking about any distributed system (not just storage or databases), there is a concept that defines the limitations of what you can do. This is known as the CAP theorem.

CAP theorem

Eric Brewer introduced the CAP theorem in the year 2000. It states that in any distributed environment, it is impossible for it to provide three guarantees.

Consistency: All the servers in the system will have the same data. So, anyone using the system will get the latest data, regardless of which node they talk to in the distributed system.Availability: All of the servers will always return data.Partition-tolerance: The system continues to operate as a whole, even if an individual server fails or cannot be reached.

By looking at these choices, you can tell that it would definitely be ideal to have all three of these things guaranteed, but it's theoretically impossible. In the real world, each NoSQL database picks two of the three options, and usually develops some kind of process to mitigate the impact of the third, unhandled property.

We'll talk about which approach CouchDB takes shortly, but there is still a bit to learn about another concept that NoSQL databases avoid: ACID.

ACID

ACID is a set of properties that apply to database transactions, which are the core of traditional relational databases. While transactions are incredibly powerful, they are also one of the things that make reading and writing quite a bit slower in relational databases.

ACID is made up of four main properties:

Atomicity: This is an all or nothing approach to dealing with data. Everything in the transaction must happen successfully, or none of the changes are committed. This is a key property whenever money or currency is handled in a system, and requires a system of checks and balances.Consistency: Data will only be accepted if it passes all of the validation in place on the database, such as triggers, data types, and constraints.Isolation: Transactions will not affect other transactions that are occurring, and other users won't see partial results of a transaction in progress.Durability: Once the data is saved, it is safe against errors, crashes, and other software malfunctions.

Again, as you read through the definition of ACID, you are probably thinking to yourself, "These are all must haves!" That may be the case, but keep in mind that most NoSQL databases do not fully employ ACID, because it's near impossible to have all of these restrictions and still have blazing fast writes to data.

So what does all of that mean?

I've given you a lot of definitions now, but let's try to wrap it together into a few simple lists. Let's talk through the advantages and disadvantages of NoSQL databases, when to use, and when to avoid NoSQL databases.

Advantages of NoSQL databases

With the introduction of NoSQL databases, there are lot of advantages:

You can do things that simply weren't possible with the processing and query power of traditional relational databases.Your data is scalable and flexible, allowing it to scale to size and complexity faster, right out of the box.There are new data models to consider. You don't have to force your data into a relational model if it doesn't make sense.Writing data is blazing fast.

As you can see, there are some clear advantages of NoSQL databases, but as I mentioned before, there are still some negatives that we need to consider.

Negatives of NoSQL databases

However, along with the good, there's also some bad:

There are no common standards; each database does things just a little bit differentlyQuerying data does not involve the familiar SQL model to find recordsNoSQL databases are still relatively immature and constantly evolvingThere are new data models to consider; sometimes it can be confusing to make your data fitBecause a NoSQL database avoids the ACID model, there is no guarantee that all of your data will be successfully written

Some of those negatives may be pretty easy for you to stomach, except for NoSQL's avoidance of the ACID model.

When you should use NoSQL databases

Now that we have a good take on the advantages and disadvantages, let's talk about some great use cases for using NoSQL databases:

Applications that have a lot of writingApplications where the schema and structure of the data might changeLarge amount of unstructured or semi-structured dataTraditional relational databases feel restricting, and you want to try something new.

That list isn't exclusive, but there are no clear definitions on when you can use NoSQL databases. Really, you can use them for just about every project.

When you should avoid NoSQL databases

There are, however, some pretty clear areas that you should avoid when storing data in NoSQL.

Anything involving money or transactions. What happens if one record doesn't save correctly because of NoSQL avoidance of the ACID model or the data isn't 100 percent available because of the distributed system?Business critical data or line of business applications, where missing one row of data could mean huge problems.Heavily-structured data requiring functionality in a relational database.

For all of these use cases, you should really focus on using relational databases that will make sure that your data is safe and sound. Of course, you can always include NoSQL databases where it makes sense.

When choosing a database, it's important to remember that "There is no silver bullet." This phrase is used a lot when talking about technology, and it means that there is no one technology that will solve all of your problems without having any side effects or negative consequences. So choose wisely!

Introduction to CouchDB

For this book and for a variety of my own projects and startups, I chose CouchDB. Let's take a historical look at CouchDB, then quickly touch on its approach to the CAP theorem, and its strengths and weaknesses.

The history of CouchDB

In April 2005, Damien Katz posted a blog entry about a new database engine he was working on, later to be called CouchDB, which is an acronym for Cluster Of Unreliable Commodity Hardware. Katz, a former Lotus Notes developer at IBM, was attempting to create a fault-tolerant document database in C++, but soon after, shifted to the Erlang OTP platform. As months went by, CouchDB started to evolve under the self-funding of Damien Katz, and in February 2008, it was introduced to the Apache Incubator project. Finally, in November 2008, it graduated as a top-level project.

Damien's team, CouchOne, merged with the Membase team in 2011 to form a new company called Couchbase. This company was formed to merge CouchDB and Membase into a new product, and increase the documentation and visibility for the product.

In early 2012, Couchbase announced that it would be shifting focus from facilitating CouchDB and moving to create Couchbase Server 2.0. This new database takes a different approach to the database, which meant that it would not be contributing to the CouchDB community anymore. This news was met with some distress in the CouchDB community until Cloudant stepped in.

Cloudant, the chief CouchDB hosting company and creator of BigCouch, a fault tolerant and horizontally scalable clustering frameworking built for CouchDB, announced that they would merge their changes back to CouchDB, and take on the role of continuing development of CouchDB.

In early 2012, at the time of writing, CouchDB's most major release was 1.1.1 in March 31, 2011. But CouchDB 1.2 is looking to be released just around the corner!