A Year of MongoDB • Hacker News Board

Re: A Year of MongoDB

#131

Post by Malshandir » Mon, May 13, 2013, 10:56 AM UTC

drorweiss wrote: post #78

eranation wrote: post #29

Earlier quoted context omitted.

All I can say is this: if the saying "Always plan to throw away your MVP" is true, then I can't see any other storage solution other than MongoDB (or a similar schema-less document storage DB) for MVPs. The speed of development and flexibility are simply worth it. Yes, it is hard to refactor a live product and move it from MongoDB to MySQL / Postgre but was done before and you only do that if you get traction, so its…

Couldn't agree more. I've worked for 15 years with relational databases and for the recent 6 months with mongodb on my startup. For me, the agility of not having to define my data in advance, and "work" so much to explain the DBMS how my schema should behave is no less than a game changer in my ability to build the MVP quickly. I just can't imagine having to invest all the labor in having to model everything I did wi…

Really? Mongo is for me not a database. And I worked like you 15 years with RDBMS and a year with mongo. Mongo has no security. Especially the Mongo Cluster Solution makes it so easy to steal and manipulate datas without notice. Everyone who has access to the server can enter the database. Implemented "security" could be turned off with a restart.

And nowadays it is so easy in a datamodel in a RDBMS to make changes. It is high flexible too.

But another worst thing in Mongo is the performance at complex queries. It is a nice bin for thinks nobody needs or to put documents in but that's it with Mongo.

Re: A Year of MongoDB

#132

Post by thedufer » Mon, May 13, 2013, 2:17 PM UTC

pkolaczk wrote: post #126

thedufer wrote: post #41

Earlier quoted context omitted.

> If somehow the database design requires joins, Mongo is fast enough to run two queries and then let you work with them in code. That's definitely not true. What if you were planning on filtering after the join? You may find yourself pulling millions of records. The bandwidth alone would bring you down. I work with MongoDB, and once in awhile I really miss joins. You can't emulate joins in any reasonable amount of t…

"What if you were planning on filtering after the join? You may find yourself pulling millions of records." Then you always filter before doing the join. Problem solved.

Are we pretending that there aren't filters that could depend on both halves of the join?

Re: A Year of MongoDB

#133

Post by junto » Tue, May 14, 2013, 9:32 AM UTC

tracker1 wrote: post #30

ericcholis wrote: post #15

I think that some people misunderstand the primary purpose of Schema-less design. It's not about typing, it's about document flexibility. It's about getting rid of EAV tables (read: Magento) and storing document-specific information. Typing obviously comes into play, but is only half the topic. If you are building a system where the schema is the same for all records, then you really shouldn't be using Schema-less de…

In a few projects I've worked on in the past year and a half, I've used EntityFramework C#, and added a Data NVarChar(MAX) field to each table.. then I added a base class that has a UseData(Action ) method that will pass a Json.Net based JObject in to be able to manipulate... adding additional properties that don't need to be indexed, and handling default values then becomes fairly easy with getters/setters. I also h…

I'd love to see a blog post on your Entity Framework JObject implementation!