Robo 3T – Formerly Robomongo Tutorial

All That You Need to Know about Robo 3T – Formerly Robomongo:

In June 2017, Robomongo was named with a brand new name called “Robo 3T”. This is the release of Robo 3T 1.1 version supported by 3.4 version of MongoDB.

Read Through => Series of Detailed MongoDB Tutorials

The decision of changing the name has been taken in the light of the fact that the Software had been through some fundamental changes and has improved a lot with respect to bugs and errors.

Introducton to Robo3t

The salient change which has to be mentioned is that the company changed its name from Robomongo to Robo 3T because of some changes in the product's trademark.

You can refer here for more information on this concern.

What on Earth is this Robo 3T Tool About?

Robo 3T is a free and lightweight GUI for MongoDB. It is a MongoDB management tool which has a shell-centric cross-platform and is supported by JSON i.e. JavaScript Object Notation. This tool is not typical of MongoDB's other administrative tools of user Interface i.e. its shell could get embedded in Mongo Shell with a whole lot of access in both Mongo CLI and Mongo GUI.

With the help of this mongo shell, a user could view, edit and delete mongo documents. Moreover, Robo 3T is a volunteered open source project and it's totally free of cost to the public.

It could be re-disseminate and could get re-modified as well by following the TOS of General public license version 3, which has been published by Free Software Foundation.

This software has been promulgated and could be redistributed for the purpose of helping people who could get assistance from it, that's why it bears no Warranty of wholesaling it, as per the rules by GNU.

For more information about GNU, you can check out GNU Licenses

Why Robo 3T?

Robo 3T is a free and machine friendly software, that uses a small number of one's resources available on a machine. It's highly appreciated and recognized as the world-famous project with highest success ratio in giving prime output.

Above all, by Robo 3T, the user doesn't have to go through the messy procedure of using tables and rows, which is typically used in rational databases. Unlike them, it is built on architecture Mongo collections and Mongo documents.

Industries Using Robo 3T

Industries using Robo 3T

About MongoDB

MongoDB is made as an open source database which supports Mongo documentation, that's why it is said to be a Document Database. As we mentioned earlier, it is an architecture for Mongo collections and Documents, where the database holds collections, which eventually bear Mongo documents in them.

The number of fields and the size varies from one Mongo document to another. The framework of MongoDB is based on Compiler language C++.

The proposed tutorial will clarify each concept in detail and would bring up a clear-cut understanding of the methodologies and procedures to make and manage a highly effective and user-friendly database.

It will be made by keeping an eye on holding conceptual handling of MongoDB for users who want to learn it in a much simpler way as possible. At the end of this comprehensive guide, the user would be able to test his expertise at a practical stage.

Preface

About DB:

The database is a bearer of collections. DB in your system holds multiple sets of files. MongoDB has the capability of bearing multiple Databases at once. It ensures facile scalability and effective execution.

What is the Collection?

In MongoDB, the collection is a package of mongo documents.

It's the same as the RDBMS table in typical database holders. The collection in MongoDB does not hold any kind of schema and is present in a single database. Mongo documents which are present in collections bear different fields. Usually, mongo documents in collections have analogous functions.

What is the Mongo Document?

Mongo documents are bearers of collection and have dynamic schema i.e. Mongo documents are not bound to have the same package of fields or architectures. They are programmed as key-value pairs.

A Specimen of the Mongo Document:

Following Snippet is an illustrative mongo document structure of the blog, which shows the key-value pair of it by commas in instances.

{
_id: ObjectId(“53a99ad6444c11ac2758a5d6”)
title: 'Robo 3T Tutorial',
description: 'MongoDB is no sql database',
by: 'Software Testing Help',
url: 'https://www.softwaretestinghelp.com',
tags: ['mongodb', 'database', 'NoSQL'],
likes: 1000,
comments: [
{
user: “john25”',
message: 'Welcome to Software Testing Help',
dateCreated: new Date(2018,8,2,5,15),
like: 5
},
{
user: “kevin12”,
message: 'Welcome to MongoDB',
dateCreated: new Date(2018,8,5,10,45),
like: 10
}
]
}

In the snippet, _id is a hexadecimal number which has 12 bytes in total. It clinches the exclusiveness in the mongo document. The user has to add _id during insertion of a mongo document. If the user doesn't do it, then MongoDB auto selects distinctive id for each mongo document.

Meanwhile, out of 12 bytes, the first four bytes are reserved for a current timestamp, three next to these four are reserved for machine id, two next to these three are reserved for a process of server and at last, the left out three bytes are used as a value that gets incremented.

Perks of MongoDB Over Typical RDBMS

Typically, the Schema of RDBMS is designed in such a way in which it shows the No. of tables and their relationships between them. Meanwhile, as mentioned earlier, there is no relationship schema present in the MongoDB.

Let’s discuss why MongoDB is a better choice for Data scientist over typical RDBMS:

  • First of all, MongoDB lacks schema. The mongo documents are the bearer of collections and No. of fields and the size varies from one mongo document to another.
  • There is a clear-cut architecture of a single object in MongoDB.
  • It lacks complex joining.
  • It holds extensive query ability because of the presence of the property which says mongo documents have an ability of dynamic queries with the help of document-based query language which is effective as MySQL.
  • It could do tuning.
  • It has the easiest scalability.
  • For conversion and mapping purposes, there is no need for objects.
  • Access data faster than typical DBMS.

Why MongoDB over RDBMS?

MongoDB holds Document-oriented storage where Data is processed in the package of JSON styled documents.

Moreover, the index could be allocated on any attribute. It ensures instant availability and could make enormous replicas. It could be auto-shared and have rich queries.

Above all, the user could get professional support from MongoDB.

Areas where MongoDB could be Used

MongoDB is the future as big data is the future. MongoDB efficiently processes big data.

It has the ability of effective content management and execution at a spot. MongoDB is the best option to use in Mobile and social media industry. It works as a data hub and manages the user data at its best.

Why is MongoDB called as a NoSQL Database?

Unlike RDBMS, where the user must have to learn MySQL, MongoDB doesn't require its user to have bulks of MySQL knowledge to start working or rely on someone else to work on Database for them.

MongoDB is not a rational database that's why it is called as a NoSQL database. It gives a sigh of relaxation to its users because of its less complex architecture.

There is no use of records that have to be bound by the same column names and types and those which revolves around the table. The figures below will explain it all. These two snippets are examples of the two tables, where one belongs to the customer and the other belongs to orders.

In both the tables, there is the presence of a mutual relationship.

Customer Table

CustomerIDCustomerNameOrderID
1Adam Gilchrist1
2Rickey Ponting2
3Shane Warne3

Order Table

OrderIDProductQuantity
1iPhone X5
2Samsung S910
3HP Pavilion x36015

While in MongoDB, There are no rational properties like RDBMS. Give a glimpse upon these two snippets.

Customer Table

CustomerID 01CustomerName
Adam Gilchrist
OrderID 001City US
CustomerID 02CustomerName
Rickey Ponting
OrderID 002Status Privilege
CustomerID 03CustomerName
Shane Warne
OrderID 003

Order Table

OrderID 001Product
iPhone X
Quantity
5
Shipment Date
August 14, 2018
OrderID 002Product
Samsung S9
Quantity
10
OrderID 003Product
HP Pavilion x360
Quantity
15

Hence, in NoSQL, the first thing one has to ponder is the absence of columns with specific column names. Plus, there is a key-value pair in all fields. Secondly, in the table of customers, First three keys and rows are alike and fourth one i.e. status and city differ from the first two rows and is not inclined to the third row.

Meanwhile, in the table which belongs to the order details, the second and third row have values which have no relationship with the fourth column.

In a nutshell, all these properties make NoSQL, the best choice over typical DBMS. The world is revolutionizing and technology is transforming steadfastly with it. In this fast era, the Business world needs the fastest solutions for their software.

With the help of DBMS like MongoDB, which is a NoSQL DB, the faster turn around time could be achievable, because of its less complexity when compared to RDBMS. When we have to review the efforts, potential, time and money, that one has to bear while using RDBMS, MongoDB gets over it in no time.

Data Modelling in MongoDB

Data present in MongoDB holds the simplest schema. A typical SQL DBMS where a user has to declare schema of a table before starting insertion of data.

As we studied, MongoDB's collections are Document-oriented and do not bound its user to the typical document structure like RDBMS. Flexibility is the most powerful attribute of MongoDB, to use it over RDBMS.

A user has to consider the following points in order to do Data modeling in MongoDB:

  • Find out the crucial needs of the desired application. For this purpose, one has to give a glance upon business necessities of application and figure out the desired data and its types for it. Following this, one has to ensure that the document architecture is figured out according to the purpose.
  • Find out the retrieval patterns of the data. If there is a need for complex query usage, then go for indexes in the data model to ensure the effectiveness of the queries.
  • Last, but not the least is ensuring inserts, updates, and deletions going on in DBMS. This could be ensured by re-evaluating the usage of indexes and built-in sharding if it has to be present in the data modeling design. This is very important to improve the effectiveness of MongoDB's environment.

Comprehensive Contrast Between SQL vs NoSQL MongoDB

Difference Between Terms and Syntax

SQL Terms/SyntaxMongoDB Terms/Syntax
DatabaseDatabase
TableCollection
RowDocument
ColumnField
IndexIndex
Table$lookup or embedded docs
Primary keyPrimary key
TransactionsTransactions

Multiple DBMS and Their Executables

Database NameDatabase ServerDatabase Client
MySQLMysqldMysql
OracleOracleSqlplus
MongoDBMongodMongo
DB2DB2 ServerDB2 Client
InformixIDSDB-Access

Precedents and Examples:

The tables above illustrate the terms, syntax, concept, and statements of multiple types of DBMS.

Let's consider the examples of SQL and MongoDB for further clarifications.

Let's consider an example of SQL, which has table name people, while MongoDB has a collection of name people as same as Tables of SQL.

MongoDB’s collection has the following prototype:

{
_id: ObjectId(“59z12ad6444n59ac2758a5x7”),
user_id:"john25",
age: 25,
status: 'A'
}

Contrast Between SQL and MongoDB Statements

CREATE and ALTER

SQL Schema StatementsMongoDB Schema Statements
CREATE TABLE employee (
id MEDIUMINT NOT NULL
AUTO_INCREMENT,
user_id Varchar(30),
age Number,
status char(1),
PRIMARY KEY (id)
)
db.employee.insertOne { {
id: "john25",
name: john,
status: "A"
} )
However, you can also explicitly create a collection:
db.createCollection (“employee”)
ALTER TABLE employee
ADD join_date DATETIME
db.employee.updateMany(
{ },
{$set: {last_name: Adam}}
)
ALTER TABLE employee
DROP COLUMN join_date
db.employee.updateMany(
{ },
{$unset: {“Age”: “”} }
)

INSERT

SQL INSERT StatementsMongoDB insertOne() Statements
INSERT INTO employee(user_id,
age,
status)
VALUES ("test001",
45,
"A")
db.employee.insertOne(
{
user_id: “john25”, age: 45, status: “A”}
)

Some SELECT Queries of SQL and MongoDB

SQL SELECT StatementsMongoDB find() Statements
SELECT *
FROM employee
db.employee.find()
SELECT id,
user_id,
status
FROM employee
db.employee.find(
{ },
{user_id: 1, status: 1}
)

SELECT user_id, status
FROM employee
db.employee.find(
{ },
{user_id: 1, status: 1, _id: 0}
)

SELECT *
FROM employee
WHERE status = "A"
db.employee.find(
{ status: “A” }
)

UPDATE Statements of SQL and MongoDB

SQL Update StatementsMongoDB updateMany() Statements
UPDATE employee
SET status = "C"
WHERE age > 25
db.employee.updateMany(
{ age: { $gt: 25 } },
{ $set: { status: "C" } }
)
UPDATE employee
SET age = age + 3
WHERE status = "A"
db.employee.updateMany(
{ status: "A" } ,
{ $inc: { age: 3 } }
)

Delete Records Of SQL and MongoDB

SQL Delete StatementsMongoDB deleteMany() Statements
DELETE FROM employee
WHERE status = "D"
db.employee.deleteMany( { status: "D" } )
DELETE FROM employeedb.employee.deleteMany({})

Theoretical Overview of Differences

When a user gets a need, where he has to go through a catharsis in which he has to take a decision from lots of ample options in front of him, then he has to select that either he has to plump for RDBMS (SQL) or Non-Rational DBMS (NoSQL).

There are some differences, and by pondering upon them, a corresponding user could take a viable decision, according to his need.

Let's have an overview of the big picture clash between these two different data structures.

The Dialect Difference: The Languages

Let's take an example of the township, where no one is bi-lingual, every person speaks the same language and that is the only form of communication among them.

In a nutshell, it says that this is the only medium from which they understand each other. If all of a sudden, the town becomes expose to another brand new language, it must be anarchic for them for adopting it in an instant, as they do not understand it or only a few might understand it.

Now consider an example of another town, where a community is bi-lingual and they speak multiple languages. Each person living in the community interact with others differently and no universal way of communication exists there. It's like as if one family is different than the others, and it doesn't affect them in any way.

These simple examples explain the core concept of SQL and MongoDB.

Let's see the contrast!!

SQL DBMS

SQL DBMS have structured query language i.e. MySQL for data manipulation.

There is no doubt about the powerfulness of MySQL language, it's the most used one among the users of DBMS and it is versatile to adopt. For complex data handling, it's the best choice. But, there is also a limitation of it and that is its rigid schema.

Because of its complex schema, one can't switch between multiple structures, they've to stick only upon one structure which they're following from the beginning. According to the first example, changing structure would be the same as changing language where everyone knows only one and in this way, it would create anarchy and mess.

NoSQL DBMS

NoSQL DBMS constitute of Dynamic Schema.

Unstructured Data could easily get stored in multiple ways i.e. it could be stored as a key-value pair or could be a column and document-oriented. This could be further explained as the user would be able to create Mongo documents without being restricted to a predefined structure, unlike the typical DBMS.

The documents would have their own structure that would be unique in its kind. The fields could be added anytime during the process and the syntax varies in every other database.

Scalability Contrast of SQL and NoSQL DBMS

SQL DBs are vertically scalable unlike NoSQL, which is horizontally scalable.

Vertically scalable means that data could be loaded on a single server by increasing RAM. Meanwhile, horizontally scalable means that multiple servers could be used i.e. increasing traffic with the help of sharding. Hence, SQL DBMS could be powerful but NoSQL is best for changing data sets.

Data Structures

SQL DBMS is based on tables while NoSQL DBs are based on documents, key-value pairs, graphs, and column orientations.

SQL DBMS is a good choice for typical data transactions like accounting and banking system. Meanwhile, for big data, NoSQL would standout the rational DBMS.

Typical Examples of RDBMS include MySQL, Oracle, Maria DB, and MS SQL Server. NoSQL Examples include MongoDB, Neo4J, CouchDB, RavenDB Cassandra, HBase, BigTable, and Redis.

Conclusion

All the above-mentioned details are put across in a nutshell for your easy understanding.

MySQL: The Plus Points

Given below are the merits of SQL Databases:

  • Old Is Gold: MySQL is old, hence it holds a quite strong ground in terms of huge community and testing.
  • Stable: MySQL is stable as it has more users.
  • Compatible: It is widely available on all major platforms and frameworks including Win, Mac, BSD, Solaris, and Linux. Multiple languages have a connection with them including C++, C#, Java, Perl, Python, and PHP.
  • Cheap: MySQL is open source and free of cost.
  • Replicability: It could be replicable among more than one node.
  • Sharding: MySQL has high sharding capability, and that, in turn, make it reliable for business.

MongoDB: The Plus Points

These are the merits of MongoDB:

  • Dynamic Schema: As mentioned before, its dynamic schema makes it the most flexible DBMS for a user.
  • Scalability: Its horizontal scalability helps in reducing the workload.
  • Management: MongoDB doesn’t require any administrative tool. It is user-friendly by both makers and administrators.
  • Speedy: Its queries get executed in no time.
  • Flexible: Its document and column orientation make it flexible and easy to use DBMS for a user.

Being an End User, What will you choose?

MySQL would be the right choice for those users and businesses which need rigid schemas and predefined structures for their businesses.

For instance, the applications and software that need lengthy transactions, i.e those that are actually used in banking and accounting systems. The systems which have surveillance services will support MySQL DBMS.

While MongoDB would be the best choice for businesses which have abundant growth and they would be requiring versatile schemas.

If it is difficult to define the schema as it gets changed in no time, then MongoDB's dynamic schema would work its best in this situation. This condition often happens in the mobile app industry, analytical systems, and content management systems.

This was just an introduction, for getting a hint of what this tutorial would bring for you in the long run. Check out our upcoming tutorial to know more about the Installation Guide of MongoDB on Windows.

PREV Tutorial | NEXT Tutorial