After working on Small to Large Scale ERP Level Softwares, I felt it very essential to write a guide for all levels of developers to know what kind of database to use in the project they are going to start. There are a number of factors that should be considered before choosing a database and database management system. In this small article, I have tried to cover all the basic things that should be taken into account before choosing a database for the project.
What are SQL Type Databases?
SQL stands for Sequential Query Language, and it is used to extract the data from the database. SQL become famous in the early 80s and it has been widely used in the large scale organizations for flexibility and excellent features. Learning SQL is not that easy it just takes some basic logic and a clear understanding of what you want to get from the database.
What are NoSQL Databases?
The NoSQL stands for "Not Only Sequential Query Language". This is because the NoSQL databases contain other features than simple SQL databases. Those features can be graph creation, document and collection creation, etc. NoSQL databases such as MongoDb and Neo4J are used for a variety of purposes when there is a need for rapid deployment and excellent speed.
Let's Talk About Difference Between MySQL and MongoDB and When to Use One
| MySQL | MongoDB |
|---|---|
| Use a Very Specific type of language to abstract data from the database. | Provide Excellent Interfaces and Methods to Extract data without writing the Difficult Queries. |
| MySQL provided the functionality of grouping and functions to get common statistics related to data. | MongoDB also provides built-in methods to fetch the very complex statistics and data that in MySQL will take a lot of time. |
| MySQL provides the facility to implement the Views, Store Procedures, and indexing, in order to make the data transactions very fast and reliable. | MongoDB offers fast data manipulation and addition. |
| MySQL provides an excellent way to handle the associations due to the concept of foreign keys and the concept of unique rows. | MongoDB uses two methods to create the Associations, first is the reference type and the other one is the use of foreign key same like that of MySQL database. |
| MySQL would be a perfect choice for large scale organizations due to its reliability and effectiveness in reports creation. | MongoDB is best when there are very few associations as handling associations in MongoDB is not something easy. |
Final Words
In this short article, I have tried to throw light on some factors and things that should be considered before choosing the Database for the different sizes of projects.
Latest comments (13)
The fourth point in the differences, you've written that mongoDB uses two methods to create the Associations, first is the reference type and the other one is the use of foreign key same like that of MySQL database.
Here, you've mentioned the same type. Referencing is where you use foreign key like feature. The another way to create a relationship is embedding.
Hmm, I guess I should have used an example there,
Let's say you have the Relation of Book and Authors so in MongoDB you can do it in the following two ways:
book {
authors: [
"Author1",
"Author2"
]
}
And Also by this way
book {
authors: [
......ids here.
]
}
so this is a minute difference.
Just a couple of notes:
SQL stands for Structured Query Language, not Sequential. SQL actually isn't that sequential as far as language properties goes, it's more of a declarative language.
MongoDb itself doesn't have foreign keys. Not in the sense that RDBMS' have, where you can declare relationships for which the engine can uphold data integrity. You may find ORMs for MongoDb that adds foreign key-like features on top of MongoDb though.
Otherwise a fine summary of the differences.
Thank you and Thanks for Pointing the Mistake, actually when we are mentioning the key of one table in other so it becomes a foreign key automatically, so I was referring to that Foreign key.
Neither! Postgresql! Muahaha.
In all seriousness though, I have to agree with @asdfdelta . Its going to come down to availability (document-based) vs consistency (relational) and normalized (relational) vs denormalized (document-based) data.
Denormalized data are usable in SQL database too.
It all depends upon the nature of the project that's you are going to work on, I have tried to elaborate on the difference between those two.
I always find the decision comes down to relational vs non-relational. Is my data going to be predominantly related to eachother, or can I leverage the structureless aspects of NoSQL. And this is not to say you cannot use both!
Good article though, NoSQL doesn't get enough attention.
Actually, the Startups Need to get their data on the server in quick succession, so MongoDB plays a very important role in the fast deployment on the production servers. So NoSQL is good when the relationships are not very much, but when there are a lot of relations you will surely be choosing the Relational Databases such as MySQL.
This is a good way to look at it! It might also be worth checking out HarperDB - a database that supports both NoSQL and SQL including joins, so you don't have to base your decision on the structure of your data.
Yes, you are quite right, I have heard about HarperDB, but I am trying to find time to test that out. That looks very interesting to me, due to its unique features.
Awesome! Hopefully you find a couple minutes to try it out sometime soon. When the time comes, these developer examples might provide a little inspiration. :)
Thank you very much for sharing the docs, I will surely check them out and write something ASAP as well.