"For a technology startup with limited resources, broadly adopting a new DBMS means betting its own future on the DBMS. "
It has become popular to attack MongoDB, but I think it is difficult to get an objective view of what people are doing with it. If you want to read a really scathing attack on MongoDB, consider this post:
But I recall reading that essay and thinking "These people don't want a document store, they want a relational database" and most of their criticism amounts to "MongoDB is not a relational database."
In my experience, you have to love map/reduce if you are going to have a positive experience with MongoDB. I mean this in the abstract sense: both your project and your mind need to be able to fit with that pattern of data flow that is called map/reduce. I'm thinking of map/reduce in broad terms: use a filter to get some data, use reduce to produce some aggregate.
I will here briefly mention a criticism I have of relational databases. Consider Wikipedia's explanation of Edgar F. Codd's life:
"Codd's theorem, a result proven in his seminal work on the relational model, equates the expressive power of relational algebra and relational calculus (which, in essence, is equivalent to first-order logic)."
and Codd's theorem:
"The domain independent relational calculus queries are precisely those relational calculus queries that are invariant under choosing domains of values beyond those appearing in the database itself. That is, queries that may return different results for different domains are excluded. An example of such a forbidden query is the query "select all tuples other than those occurring in relation R", where R is a relation in the database. Assuming different domains, i.e., sets of atomic data items from which tuples can be constructed, this query returns different results and thus is clearly not domain independent. Codd's Theorem is notable since it establishes the equivalence of two syntactically quite dissimilar languages: relational algebra is an imperative, variable-free language, while relational calculus is a logical language with variables and quantification."
Clearly, this assumes that the relations among the data are known. I work mostly with early stage startups. The entrepreneurs I work with have no real idea about what relations they want establish among their data. They are an exploratory phase. I believe these entrepreneurs should be described as "pre Codd". If you force them to specify relations among their data, you will get answers exactly as useful as these:
MongoDB is useful in this context. Start acquiring data. Don't pretend you know what your schema is. You do not know what your schema is. The entrepreneur who perfectly understands what sort of data they want, and what the relations will be among the different sets of data, before the startup has launched, is a bit like Newton and Einstein: you can expect 1 such person every 200 years.
"For a technology startup with limited resources, broadly adopting a new DBMS means betting its own future on the DBMS. "
It has become popular to attack MongoDB, but I think it is difficult to get an objective view of what people are doing with it. If you want to read a really scathing attack on MongoDB, consider this post:
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...
But I recall reading that essay and thinking "These people don't want a document store, they want a relational database" and most of their criticism amounts to "MongoDB is not a relational database."
In my experience, you have to love map/reduce if you are going to have a positive experience with MongoDB. I mean this in the abstract sense: both your project and your mind need to be able to fit with that pattern of data flow that is called map/reduce. I'm thinking of map/reduce in broad terms: use a filter to get some data, use reduce to produce some aggregate.
I will here briefly mention a criticism I have of relational databases. Consider Wikipedia's explanation of Edgar F. Codd's life:
http://en.wikipedia.org/wiki/Edgar_F._Codd
"Codd's theorem, a result proven in his seminal work on the relational model, equates the expressive power of relational algebra and relational calculus (which, in essence, is equivalent to first-order logic)."
and Codd's theorem:
"The domain independent relational calculus queries are precisely those relational calculus queries that are invariant under choosing domains of values beyond those appearing in the database itself. That is, queries that may return different results for different domains are excluded. An example of such a forbidden query is the query "select all tuples other than those occurring in relation R", where R is a relation in the database. Assuming different domains, i.e., sets of atomic data items from which tuples can be constructed, this query returns different results and thus is clearly not domain independent. Codd's Theorem is notable since it establishes the equivalence of two syntactically quite dissimilar languages: relational algebra is an imperative, variable-free language, while relational calculus is a logical language with variables and quantification."
Clearly, this assumes that the relations among the data are known. I work mostly with early stage startups. The entrepreneurs I work with have no real idea about what relations they want establish among their data. They are an exploratory phase. I believe these entrepreneurs should be described as "pre Codd". If you force them to specify relations among their data, you will get answers exactly as useful as these:
http://blog.jimmyr.com/Funny_student_Exam_Answers_13_2008.ph...
MongoDB is useful in this context. Start acquiring data. Don't pretend you know what your schema is. You do not know what your schema is. The entrepreneur who perfectly understands what sort of data they want, and what the relations will be among the different sets of data, before the startup has launched, is a bit like Newton and Einstein: you can expect 1 such person every 200 years.