MongoDB is amazing... until you go further and discover graph databases such as Neo4j, OrientDB, et al.
The one thing MongoDB seems to have forgotten about is relationships between entities, that can be themselves messy, hence the idea of using graphs to enjoy the goodness of traversal algorithms for DB searches.
didn't know about that... however, it's still an adaptation, an afterthought. That means all graph-related stuff happens outside of the DB space, in library space, so it's going to sacrifice performance compared to native graph DBs
anyway, please don't get me wrong, I don't want to diminish MongoDB at all, it's an excellent product with its space in the market, still great at a number of things
No problem, and you are right that a purpose-built database should perform better for its use cases than a general purpose database. But I only rely on execution plans to understand the performance difference, and didn't test PuppyGraph on MongoDB yet - but that will come
Mongo is in no way "purpose-built" for persisting business entity data, and general purpose database engines have been optimized for over 50 years to quickly, efficiently, and reliably store and retrieve relational data. They also provide relational integrity, which typically must be coded and maintained manually in document databases like Mongo.
Please, please learn more about SQL databases, and stop these misinformed and misleading posts.
Never said that 🤷🏼♂️. MongoDB is a general purpose database.
Please, please learn more about SQL databases
I'm writing this because I know SQL databases. I'm a big fan and have worked 30 years with Dev and Ops on DB2, Oracle, PostgreSQL, and others. I don't know what makes you angry. I wrote this to provide an example behind "The World Is Too Messy for SQL to Work" for those who want to understand where it might come from.
There's no need to read it if you are convinced that all data processing must happen in the database, on a fully normalized data model with all integrity constraints and stored procedures. You are right. But some developers and architects might think differently, and it can be interesting to listen to them and try to understand.
MongoDB is amazing... until you go further and discover graph databases such as Neo4j, OrientDB, et al.
The one thing MongoDB seems to have forgotten about is relationships between entities, that can be themselves messy, hence the idea of using graphs to enjoy the goodness of traversal algorithms for DB searches.
What about a graph query language on top of MongoDB:
PuppyGraph - Querying MongoDB Atlas Data as a Graph
didn't know about that... however, it's still an adaptation, an afterthought. That means all graph-related stuff happens outside of the DB space, in library space, so it's going to sacrifice performance compared to native graph DBs
anyway, please don't get me wrong, I don't want to diminish MongoDB at all, it's an excellent product with its space in the market, still great at a number of things
No problem, and you are right that a purpose-built database should perform better for its use cases than a general purpose database. But I only rely on execution plans to understand the performance difference, and didn't test PuppyGraph on MongoDB yet - but that will come
Mongo is in no way "purpose-built" for persisting business entity data, and general purpose database engines have been optimized for over 50 years to quickly, efficiently, and reliably store and retrieve relational data. They also provide relational integrity, which typically must be coded and maintained manually in document databases like Mongo.
Please, please learn more about SQL databases, and stop these misinformed and misleading posts.
Never said that 🤷🏼♂️. MongoDB is a general purpose database.
I'm writing this because I know SQL databases. I'm a big fan and have worked 30 years with Dev and Ops on DB2, Oracle, PostgreSQL, and others. I don't know what makes you angry. I wrote this to provide an example behind "The World Is Too Messy for SQL to Work" for those who want to understand where it might come from.
There's no need to read it if you are convinced that all data processing must happen in the database, on a fully normalized data model with all integrity constraints and stored procedures. You are right. But some developers and architects might think differently, and it can be interesting to listen to them and try to understand.
I don't know why you think I'm angry. I'm very calmly stating that what you're telling people is wrong and calmly asking you to stop.
I've worked for 30 years cleaning up expensive messes caused by people who are convinced that they know what they're doing.