Slashdot Mirror
Why My Team Went With DynamoDB Over MongoDB
Nerval's Lobster writes "Software developer Jeff Cogswell, who matched up Java and C# and peeked under the hood of Facebook's Graph Search, is back with a new tale: why his team decided to go with Amazon's DynamoDB over MongoDB when it came to building a highly customized content system, even though his team specialized in MongoDB. While DynamoDB did offer certain advantages, it also came with some significant headaches, including issues with embedded data structures and Amazon's sometimes-confusing billing structure. He offers a walkthrough of his team's tips and tricks, with some helpful advice on avoiding pitfalls for anyone interested in considering DynamoDB. 'Although I'm not thrilled about the additional work we had to do (at times it felt like going back two decades in technology by writing indexes ourselves),' he writes, 'we did end up with some nice reusable code to help us with the serialization and indexes and such, which will make future projects easier.'"
They must run their company pretty different than where I work.
Where I work, the most senior and backstabby developer saddles the worst tools he can find on the rest of the team, and then blames them (behind their backs of course) for the results of his poor decision making.
But MongDB is web scale.
"Those who don't understand SQL are condemned to reinvent it, poorly." (with apologies to Harry Spencer).
The world's burning. Moped Jesus spotted on I50. Details at 11.
But I want Dice to tell me all the ways in which backend specialists are critical to online games!
We decided that MongoDB was adequate but didn't leverage the synergies we were trying to harvest from our development methodologies.
We looked at GumboDB and found it was lacking in visualization tools to create a warehouse for our data that would provide a real-time dashboard of the operational metrics we were seeking.
Next up was SuperDuperDB which was great from a client-server-man-in-the-middle perspective but required a complex LDAP authentication matrix that reticulated splines within our identity management roadmap.
After that I quit. I hear they are using Access 95 with VBA.
Wearing pants should always be optional.
"However, the articles also contained data less suited to a traditional database. For example, each article could have multiple authors, so there were actually more authors than there were articles."
Good god, how would he model invoices with multiple line items? Where, you know, there were actually more line items than invoices?! Mind blown.
Or customers that might belong to zero more demographics? There could be more customers than defined demographics to tag them with... or less... we don't even know and it could change as more of either are added!!
We need a whole new database paradigm!
Or the sample Northwind database that's been shipping with access since the 90's.
I'm sorry that I did not use the word "Ironically" correctly. You win internet.