Switching from RDMS to MongoDB
The people who promote MongoDB are smart. They don't push MongoDB at you. They help you make intelligent decisions. After all, they know MongoDB is new. They don't just recommend migrating your 10+ years old RDMS-based applications to MongoDB. More likely, they would instead recommend that you consider creating new requirements and applications in MongoDB.
Now that's marketing at its finest! It's not about penetration. It's about adoption. It's almost like a reverse psychology. "MongoDB is not for everyone." Is that a challenge? Not exactly, but the effect in a sense is that it is. True, there are requirements that may seem meant to be for RDMS. However, there is nothing stopping anyone to give MongoDB a try. After all, if you're going to write something from scratch, and if MongoDB offers a hint of promise, why not, right?
The taste of quick TOT (turn-around-time) in developing MongoDB-based applications is addictive. From conceptualization to realization, it is much, much faster than going through the entire exercise of properly designing RDMS schemas, tables, relationships, constraints, indexes, etc.. Just go ahead and dive into just getting those fields down into documents and sub-documents and what have you. Everything can be easily put in place. There's no foresight, or lack of it, to worry about. Everything can be done now, delivered soon and easily enhanced later.
Rapid application development (RAD) is never as true as it is today than ever. With the MEAN stack for example, applications can be planned, designed, developed and deployed in typical sprints of two weeks. Estimates no longer need to play around the typical 30 to 90 days period of analysis, design, DEV, QA, UAT and production releases. Indeed, an agile sprint can be a realistic enough estimate. It's amazing!
No one really recommends that you migrate your RDMS apps to MongoDB. Even MongoDB people don't do that. However, if you do find a new requirement that can let you give MongoDB a try, do it. Even just for R&D or for learning purposes. You'll be surprised how well your R&D work can actually fit in as the finished product.
Now that's marketing at its finest! It's not about penetration. It's about adoption. It's almost like a reverse psychology. "MongoDB is not for everyone." Is that a challenge? Not exactly, but the effect in a sense is that it is. True, there are requirements that may seem meant to be for RDMS. However, there is nothing stopping anyone to give MongoDB a try. After all, if you're going to write something from scratch, and if MongoDB offers a hint of promise, why not, right?
The taste of quick TOT (turn-around-time) in developing MongoDB-based applications is addictive. From conceptualization to realization, it is much, much faster than going through the entire exercise of properly designing RDMS schemas, tables, relationships, constraints, indexes, etc.. Just go ahead and dive into just getting those fields down into documents and sub-documents and what have you. Everything can be easily put in place. There's no foresight, or lack of it, to worry about. Everything can be done now, delivered soon and easily enhanced later.
Rapid application development (RAD) is never as true as it is today than ever. With the MEAN stack for example, applications can be planned, designed, developed and deployed in typical sprints of two weeks. Estimates no longer need to play around the typical 30 to 90 days period of analysis, design, DEV, QA, UAT and production releases. Indeed, an agile sprint can be a realistic enough estimate. It's amazing!
No one really recommends that you migrate your RDMS apps to MongoDB. Even MongoDB people don't do that. However, if you do find a new requirement that can let you give MongoDB a try, do it. Even just for R&D or for learning purposes. You'll be surprised how well your R&D work can actually fit in as the finished product.
Comments
Post a Comment