• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

I Like Kill Nerds

The blog of Australian Front End / Aurelia Javascript Developer & brewing aficionado Dwayne Charrington // Aurelia.io Core Team member.

  • Home
  • Aurelia 2
  • Aurelia 1
  • About
  • Aurelia 2 Consulting/Freelance Work

MongoDB Isn’t As Bad As You Think

General · March 27, 2014

I, too used to be a MongoDB naysayer and lets face it, in its early days and even up until recently MongoDB was a steaming pile of shit. Not only that, but completely forgoing things we take for granted in a traditional RDMS is something many have a hard time getting accustomed too (hello transactions).

Yes, prior to version 2.0 of MongoDB there were a few issues, one of those issues namely being the global write lock blocking all queries problem. In version 2.0 they basically addressed the issue, in version 2.2 they removed global write locks altogether.

After prototyping a little something-something I am working on in Node.js and MongoDB, I’ve changed my tune. I hadn’t used MongoDB in a while and decided to give it another shot on this project because I don’t need to define a schema, well I sort of do because I am using Mongoose JS, but that is besides the point.

Most of the hate directed at MongoDB is a lack of understanding of the tool being used. If you don’t understand what you’re using, why even bother using it? MongoDB is no different.

A bad mechanic will always blame his own tools. A bad developer or systems administrator will always blame the tools and or language instead of themselves. Blindly using something just because highscalability.com is talking about it and failing to understand how to appropriately use it is nobody’s fault but your own.

Sarah Mei, a Ruby developer who helped out on a project that tried to compete against Facebook and ultimately failed called Diaspora recently posted an article titled: Why You Should Never Use MongoDB.

Basically the TL;DR was: don’t use a non-relational database for relational data. This is an obvious misjudgement on the development teams part. It’s not the fault of MongoDB it was made to try and work for the wrong purpose.

Every time a feature changes or I want to add something new in or remove something old, I don’t need to fire up Navicat, write a migration file or use PHPMyAdmin to change my database structure. And herein lies the beauty of MongoDB and pretty much any other key/value store type database: the ability to rapidly prototype an evolving application.

I haven’t decided if MongoDB will be used for the end-result as it is a social networking type application, but so far I have not run into any problems using it and actually find it enjoyable.

While I am not currently using MongoDB at scale, for prototyping purposes it is more than adequate. And even if I only use it for this stage of the project, it has been more beneficial than MySQL ever could be in similar circumstances.

Dwayne

Leave a Reply Cancel reply

0 Comments
Inline Feedbacks
View all comments

Primary Sidebar

Popular

  • I Joined Truth Social Using a VPN and Editing Some HTML to Bypass the Phone Verification
  • Testing Event Listeners In Jest (Without Using A Library)
  • How To Get The Hash of A File In Node.js
  • Thoughts on the Flipper Zero
  • Waiting for an Element to Exist With JavaScript
  • How To Paginate An Array In Javascript
  • How To Mock uuid In Jest
  • How To Decompile And Compile Android APK's On A Mac Using Apktool
  • How To Get Last 4 Digits of A Credit Card Number in Javascript
  • Wild Natural Deodorant Review

Recent Comments

  • CJ on Microsoft Modern Wireless Headset Review
  • Dwayne on Microsoft Modern Wireless Headset Review
  • CJ on Microsoft Modern Wireless Headset Review
  • john on Microsoft Modern Wireless Headset Review
  • Dwayne on Why You Should Be Using globalThis Instead of Window In Your Javascript Code

Copyright © 2023 · Dwayne Charrington · Log in

wpDiscuz