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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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.
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.
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.
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.