
SQL databases have been rocking the programming world since the 70’s. Lots of stuff have changed since, we have something called “internets” and it’s revolutionizing how stuff was done before. We buy, sell, contact, write, play, entertain, watch movies (in 3D heck yeah!), get scammed by Nigerian, tweet about cat, download music for free on the INTERNETS etc. And some people have been jailed, sued, reprimanded because of the INTERNETS. So, “I like turtle”. Yeah! Famous quotes can make you become an internet sensation. “So hide your wife, hide your kids and hide your husband, …. ”, because there is a bed intruder out there.
Because of the internet, data has grown to a point where relational databases are not the right fit . Not all data are relational. Hence several companies (Google, Facebook, Amazon…) start building their own datastore.
2010, in my opinion, was the year of scalability, big data, and the rise of the NoSQL movement.
NoSQL was first defined as NO to SQL. But later was changed to Not Only SQL, because SQL still excels in some area while NoSQL DB will kick SQL’s derriere in some. The term “NoSQL” typically refers to non-relational, distributed databases that do not require fixed-table schemas.
NoSQL databases are schema-less, schema-full, schema-mixed. And the best part, they don’t require any JOINs. What? Yes sir! No JOINs.
Most modern relational databases have shown poor performance on certain data-intensive applications, including indexing a large number of documents, serving pages on high traffic websites and delivering streaming media. NoSQL on the other side provides heavy read/write workloads. It allows rapid application development and your schema lives within your application.
Some people will find it really hard to understand how the NoSQL DB work. One thing I will suggest first, is not to think like SQL (UNSQL yourself); But unfortunately after writing “SELECT * FROM TABLE” so many times, it’s hard to get out of there. But I’m going to try my best to break it down…. But on some real “shizzle”, one should make his/her own extended research on the NoSQL DB to know more.
Let’s get to know some of the most popular, and we’ll leave the best, for last (playing african drum in your head and sing: Mongo, Mongo, Mongo…)
Classes of NoSQL DB
There are three main classes of NoSQL DB.
Key/Value Store. It holds data as Key-Value pair such that values are indexed to be retrieved by keys. Key/Value Store DB can hold structured and unstructured data. In this family of DB there are Riak , Redis.
Column-Oriented DB. It contains one extendable column of closely related data rather than sets of information in a strictly structured table of columns and rows as is found in relational databases. In this family there is Cassandra, HBase.
Document Based DB. Data is stored and organized as a collection of documents. Users are allowed to add any number of fields of any length to a document. They tend to store JSON-based documents in their database. In this class, there is MongoDB, CouchDB.
For a full list of NoSQL DB, CLICK HERE (you see what I did here?)
Of course before choosing a database from any of these classes one should make their due diligence, tests and benchmarks. So many people jumped from relational to NOSQL just to go back to relational again because they were doing it wrong or didn’t know what they were doing.
Anyway…

MongoDB is the Tiger Blood of Database. When you use it, it’s #Winning.
Now among all the NoSQL db, I prefer Mongo. Well, MongoDB makes sense. It is the scripting language of the databases. I’ve been working with it for more than a year now. While it may not solve all relational database issues, putting the right thought in your application and your database schema will make you kick relational databases’ butt (and it’s fun to do).
Installing and running MongoDB is super easy. You just download, and launch the mongod file. Upgrading to the latest version is as easy as making coffee after 2pm. You just replace the old binaries with the new one and you are up to date and MongoDB comes with replication and sharding.
Like most NoSQL DB, MongoDB is Webscale, you can use it for MapReduce, you can store files in it. You can make it “Like Turtle” technically do anything. It is just a versatile storage engine. Whenever you feel like looking at a NoSQL database that have a similarity to your favorite relational database, check out MongoDB.
How would a document look like in Mongo?
MongoDB Documents are like JSON, and is trongly typed. It can hold: String, Array, Integer, Float etc…
The collection below holds three documents.
{
"compID": 1111, // Holds integer
"companyName": "RedVentures", // holds string
"isLive": true, // hold boolean
"uniqueContactFields":["Address","PhoneNumber"], // Holds array
"avgLoadTime":0.17, // holds float
}
{
"compID": 2222,
"companyName": "DirectTV",
"isLive": true,
"uniqueContactFields":["LastName","HomePhone","Zip"],
"avgLoadTime":0.15,
}
{
"compID": 333,
"companyName": "NurfSquad",
"isLive": false,
"uniqueContactFields":["LastName","Zip","PhoneNumber"],
"avgLoadTime":0.12,
}
Let get some terminology before we go into more codes.
10Gen, the company behind MongoDB, made sure there are some similarities between SQL and Mongo while keeping it NoSQL in a non relational world.
In MongoDB a database is just like a database in relational db. “Duh!”
Collections in MongoDB can be like Tables and Documents are like Rows.
So a Document is in a Collection, and the Collection is in the Database. And of course a Collection will have more than one Document, and a database can have more than one Collection.
So the similarities are there except it’s bananas fun!
Now let’s connect to the DB:
$Mongo = new mongo();
$MongoCorpDB = $Mongo->selectDB(“RVWins”)
$Companies = $MongoCorpDB->selectCollection(“Companies”);
Get all the companies:
$allCompanies = $Companies->find();
Now, get all companies that are live
$allCompanies = $Companies->find(array(“isLive”=>true));
It will return the documents having companyName: RedVentures & DirectTV All companies that are not live
$allCompanies = $Companies->find(array(“isLive”=>false));
It will return the documents having companyName: NurfSquad.
Now let’s find documents based on criteria having values in an array. All Companies where uniqueContactFields = PhoneNumber
$allCompanies = $Companies->find(array(“uniqueContactFields”=>”PhoneNumber”))
It will return the documents having companyName: RedVentures and NurfSquad. As you can see, uniqeContactFields is an array, and Mongo can find documents matching a criteria in an array. Now let’s get all the documents again. It will sort all document by avgLoadTime from highest to lowest, and return only 10.
$allCompanies = $Companies->find()->sort(array("avgLoadTime"=>-1))->limit(10);
foreach($allCompanies as $company){
print("{$company[companyName]} average load time: {$company[avgLoadTime]}");
print("<br>");
}
As you ca see, working with MongoDB is like working with your own classes in your own projects. That’s #bi-winning.
And what if I want to update some data. Well let’s change the avgLoadTime for the compID: 2222 to 0.25
$Companies->update(array(compID:222),array('$set'=>array("avgLoadTime":0.25)));
That was easy right? Now let’s say someone wants to add one extra field for only the companyName NurfSquad. Let’s add a field hasHaitian, where it’s a boolean.
$Companies->update(array(compID:333),array('$set'=>array("hasHaitian":true)));
Now the NurfSquad document has a field called hasHaitian, while the others don’t have it. Now let’s look at our final db data. I also added a members fields, where it holds an object of all members with their properties
{
"compID": 1111,
"companyName": "RedVentures",
"isLive": true,
"uniqueContactFields":["Address","PhoneNumber"],
"avgLoadTime":0.17,
}
{
"compID": 2222,
"companyName": "DirectTV",
"isLive": true,
"uniqueContactFields":["LastName","HomePhone","Zip"],
"avgLoadTime":0.25,
}
{
"compID": 333,
"companyName": "NurfSquad",
"isLive": false,
"uniqueContactFields":["LastName","Zip","PhoneNumber"],
"avgLoadTime":0.12,
"hasHaitian":true,
"members":[
{
"name":"Colin",
"seat":"2-W-123"
},
{
"name":"Brandon",
"seat":"2-V-12"
},
{
"name":"Mardix",
"seat":"1-V-34",
"isHaitian":true
},
{
"name":"Ryan",
"seat":"3-A-13"
},
{
"name":"Deny",
"seat":"4-P-235"
},
{
"name":"Kyle",
"seat":"1-W-123"
},
{
"name":"Stephens",
"seat":"2-Q-12"
},
]
}
That’s how the document database look like. As simple as it is, as simple you get the data. I hope you get a good idea, and this can spin your imagination to the world of NoSQL.
Next time you have a project and you can decide which database to pick, take a look at MongoDB, you will be #winning!
"compID": 1111,
"companyName": "RedVentures",
"isLive": true,
"uniqueContactFields":["Address","PhoneNumber"],
"avgLoadTime":0.17,
}
{
"compID": 2222,
"companyName": "DirectTV",
"isLive": true,
"uniqueContactFields":["LastName","HomePhone","Zip"],
"avgLoadTime":0.25,
}
{
"compID": 333,
"companyName": "NurfSquad",
"isLive": false,
"uniqueContactFields":["LastName","Zip","PhoneNumber"],
"avgLoadTime":0.12,
"hasHaitian":true,
"members":[
{
"name":"Colin",
"seat":"2-W-123"
},
{
"name":"Brandon",
"seat":"2-V-12"
},
{
"name":"Mardix",
"seat":"1-V-34",
"isHaitian":true
},
{
"name":"Ryan",
"seat":"3-A-13"
},
{
"name":"Deny",
"seat":"4-P-235"
},
{
"name":"Kyle",
"seat":"1-W-123"
},
{
"name":"Stephens",
"seat":"2-Q-12"
},
]
}