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.
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.
Table of Contents:
- What on Earth is this Robo 3T Tool About?
- Why Robo 3T?
- About MongoDB
- Preface
- Perks of MongoDB Over Typical RDBMS
- Why MongoDB over RDBMS?
- Areas where MongoDB could be Used
- Why is MongoDB called as a NoSQL Database?
- Data Modelling in MongoDB
- Comprehensive Contrast Between SQL vs NoSQL MongoDB
- Contrast Between SQL and MongoDB Statements
- Theoretical Overview of Differences
- The Dialect Difference: The Languages
- SQL DBMS
- NoSQL DBMS
- Scalability Contrast of SQL and NoSQL DBMS
- Data Structures
- Conclusion
- Was this helpful?
- Recommended Reading
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 that 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 volunteer open-source project and it’s totally free of cost to the public.
It could be re-disseminated 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
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
| CustomerID | CustomerName | OrderID |
|---|---|---|
| 1 | Adam Gilchrist | 1 |
| 2 | Rickey Ponting | 2 |
| 3 | Shane Warne | 3 |
Order Table
| OrderID | Product | Quantity |
|---|---|---|
| 1 | iPhone X | 5 |
| 2 | Samsung S9 | 10 |
| 3 | HP Pavilion x360 | 15 |
While in MongoDB, There are no rational properties like RDBMS. Give a glimpse upon these two snippets.
Customer Table
| CustomerID 01 | CustomerName Adam Gilchrist | OrderID 001 | City US |
| CustomerID 02 | CustomerName Rickey Ponting | OrderID 002 | Status Privilege |
| CustomerID 03 | CustomerName Shane Warne | OrderID 003 |
Order Table
| OrderID 001 | Product iPhone X | Quantity 5 | Shipment Date August 14, 2018 |
| OrderID 002 | Product Samsung S9 | Quantity 10 | |
| OrderID 003 | Product 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/Syntax | MongoDB Terms/Syntax |
|---|---|
| Database | Database |
| Table | Collection |
| Row | Document |
| Column | Field |
| Index | Index |
| Table | $lookup or embedded docs |
| Primary key | Primary key |
| Transactions | Transactions |
Multiple DBMS and Their Executables
| Database Name | Database Server | Database Client |
|---|---|---|
| MySQL | Mysqld | Mysql |
| Oracle | Oracle | Sqlplus |
| MongoDB | Mongod | Mongo |
| DB2 | DB2 Server | DB2 Client |
| Informix | IDS | DB-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 Statements | MongoDB 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 Statements | MongoDB 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 Statements | MongoDB 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 Statements | MongoDB 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 Statements | MongoDB deleteMany() Statements |
|---|---|
| DELETE FROM employee WHERE status = "D" | db.employee.deleteMany( { status: "D" } ) |
| DELETE FROM employee | db.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.