4 ms·

I beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don'

I beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don't need multi-document transactions as often, because the data is already together in a single document. But when you do need multi-document transactions (a small percentage of applications do, and only few use cases inside those applications), they are now available. There is no speed impact on cases when you don't use them. And most of the time, you shouldn't use them, otherwise you wouldn't be capitalizing on the advantages of JSON. I think that's a game changer, but then again: I do work for MongoDB.

mason55 9y ago
> otherwise you wouldn't be capitalizing on the advantages of JSON Shouldn't this be "otherwise you wouldn't be capitalizing on the advantages of a schemaless, document-oriented database"? The fact that it's JSON (vs. some other format) seems immaterial
- matwood 9y ago
  As an aside, I hate the term 'schemaless' because there is always a schema. https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-using-a-schemaless-database/ https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-us...
  - lukaseder 9y ago
    Yep. Schema-on-read (E.g. MongoDB) or schema-on-write (E.g. Oracle)
- metheus 9y ago
  Quibble: “schemaless” isn’t accurate, MongoDB supports schema (JSON Schema, in fact). We often say “dynamic schema”. But your main point is good—- JSON isn’t the essence of it. And yet it’s part of it, in that you could store XML and still be a document DB; MongoDB definitely chose JSON as the medium deliberately.
jeremiep 9y ago
Its usually only after a while you realize almost every piece of meaningful data is relational. It just didn't look that way when the project started. But now you're committed on the wrong database and its very costly to switch back to SQL. Literally every project I saw using MongoDB ended up going back to SQL within the first 2 years after realizing the data is indeed very much relational and theres no clean way to model it using documents. You always end up with either tons of duplication across documents, which is hell to maintain, or tons of multi-document queries with hacks to look ACID, which is also hell to maintain. Sure Mongo makes it easy to prototype applications, but it makes it very complex to build robust and maintainable software. Its especially bad if you think your data isn't relational, because it almost certainly is. Disclaimer: I believe Datomic to be the game changing database; because it values simplicity and composition and these attributes drive the entire design.
- fnayr 9y ago
  Video games storing player data are a great example of nonrelational data. I'm intending on writing a blog post after I finish my game detailing the structure of data I store and why it was so perfect for mongodb.
  - javiermaestro 9y ago
    Please do, because I'm interested in seeing how non-relational it is... I truly believe it has to be otherwise, so I'd love to read your findings!
    - imtringued 9y ago
      You still need ACID transactions over multiple entries even if your data is nonrelational otherwise there is the potential for item and money duping bugs. A simple example would be a marketplace. Player buys item X with Y gold from another player. 1. Server checks that item X exists. 2. Server checks that the player has at least Y gold. 3. Server removes the gold from the player 4. Server gives gold to the seller. 5. Server removes item from marketplace. 6. Server adds item to inventory. What if someone maliciously crafts two requests in a way that step 2 of the second request happens before step 3 of the first request? The money is deducted properly but the account can now have a negative balance and there are now two instances of the item.
woah 9y ago
As a developer: What? Almost everything is relational. I do appreciate Mongo's query language and ease of use (it was the first DB I learned), but your statement is ludicrous. Think about a basic blog system. You'll have relations between authors, posts, categories, and comments. In my experience, Mongo is most often used with ORMs that emulate joins, like Mongoose. And the possibility of data inconsistency due to lack of transactions is ignored, or patched over with cleanup scripts after the fact.
ZenoArrow 9y ago
How does MongoDB handle schema changes? For example, let's say I want to add a mobile phone field to a customer record type. How would I go about doing that in MongoDB?
- mustardo 9y ago
  The onerous is mostly on the developer... For any "real" system that is going to be in production for a long time this becomes a real problem There are tools to "migrate" data but they come with all the limitations of the Mongo isolation model Typically you either * Write ad hoc (possibly using some tooling) code to iterate over your old data adding or mutating the field(s) in question * Write queries such that they can handle the data being present, absent or in different forms for all of time. As you could expect this is a large burden
- drmirror 9y ago
  The short answer is: just do it. You can add any field to any document at any time. That's the beauty of JSON documents without schema constraints. Then of course you need to let your application understand that. But it turns out it's almost trivial to make an application display a phone number field if it finds one, and not display a phone number if there isn't one in the document.
  - mustardo 9y ago
    This is true It hurts when the next requirement comes along something like... "As a user I want to have a home, work, and mobile phone number" Now you have 3 "versions" of your implicit "schema" to contend with 1) No phoneNumber 2) phoneNumber and mapping it into / out of one of the three phone numbers in the UI 3) objects with three properties homePhoneNumber, workPhoneNumber, mobilePhoneNumber etc Then the business comes up with "As a user I want to have arbitrary phone numbers that I can label" now the developers start to squeal RDBMS + SQL is no panacea but having DDL operations like the following (all probably syntactically invalid but you get the idea) out of the box is incredibly powerful. ALTER TABLE user RENAME COLUMN phone_number TO home_phone_number; ALTER TABLE user ADD COLUMN work_phone VARCHAR(32) NOT NULL; CREATE TABLE phone_number (id BIGINT NOT NULL, user_id BIGINT NOT NULL, name VARCHAR(64) NOT NULL, phone_number VARCHAR(32) NOT NULL); I have had reasonable success using MongoDB as a store of "things that happened" and will never change

mason55 9y ago

> otherwise you wouldn't be capitalizing on the advantages of JSON Shouldn't this be "otherwise you wouldn't be capitalizing on the advantages of a schemaless, document-oriented database"? The fact that it's JSON (vs. some other format) seems immaterial

matwood 9y ago
As an aside, I hate the term 'schemaless' because there is always a schema. https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-using-a-schemaless-database/ https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-us...
- lukaseder 9y ago
  Yep. Schema-on-read (E.g. MongoDB) or schema-on-write (E.g. Oracle)
metheus 9y ago
Quibble: “schemaless” isn’t accurate, MongoDB supports schema (JSON Schema, in fact). We often say “dynamic schema”. But your main point is good—- JSON isn’t the essence of it. And yet it’s part of it, in that you could store XML and still be a document DB; MongoDB definitely chose JSON as the medium deliberately.

jeremiep 9y ago

Its usually only after a while you realize almost every piece of meaningful data is relational. It just didn't look that way when the project started. But now you're committed on the wrong database and its very costly to switch back to SQL. Literally every project I saw using MongoDB ended up going back to SQL within the first 2 years after realizing the data is indeed very much relational and theres no clean way to model it using documents. You always end up with either tons of duplication across documents, which is hell to maintain, or tons of multi-document queries with hacks to look ACID, which is also hell to maintain. Sure Mongo makes it easy to prototype applications, but it makes it very complex to build robust and maintainable software. Its especially bad if you think your data isn't relational, because it almost certainly is. Disclaimer: I believe Datomic to be the game changing database; because it values simplicity and composition and these attributes drive the entire design.

fnayr 9y ago
Video games storing player data are a great example of nonrelational data. I'm intending on writing a blog post after I finish my game detailing the structure of data I store and why it was so perfect for mongodb.
- javiermaestro 9y ago
  Please do, because I'm interested in seeing how non-relational it is... I truly believe it has to be otherwise, so I'd love to read your findings!
  - imtringued 9y ago
    You still need ACID transactions over multiple entries even if your data is nonrelational otherwise there is the potential for item and money duping bugs. A simple example would be a marketplace. Player buys item X with Y gold from another player. 1. Server checks that item X exists. 2. Server checks that the player has at least Y gold. 3. Server removes the gold from the player 4. Server gives gold to the seller. 5. Server removes item from marketplace. 6. Server adds item to inventory. What if someone maliciously crafts two requests in a way that step 2 of the second request happens before step 3 of the first request? The money is deducted properly but the account can now have a negative balance and there are now two instances of the item.

woah 9y ago

As a developer: What? Almost everything is relational. I do appreciate Mongo's query language and ease of use (it was the first DB I learned), but your statement is ludicrous. Think about a basic blog system. You'll have relations between authors, posts, categories, and comments. In my experience, Mongo is most often used with ORMs that emulate joins, like Mongoose. And the possibility of data inconsistency due to lack of transactions is ignored, or patched over with cleanup scripts after the fact.

ZenoArrow 9y ago

How does MongoDB handle schema changes? For example, let's say I want to add a mobile phone field to a customer record type. How would I go about doing that in MongoDB?

mustardo 9y ago
The onerous is mostly on the developer... For any "real" system that is going to be in production for a long time this becomes a real problem There are tools to "migrate" data but they come with all the limitations of the Mongo isolation model Typically you either * Write ad hoc (possibly using some tooling) code to iterate over your old data adding or mutating the field(s) in question * Write queries such that they can handle the data being present, absent or in different forms for all of time. As you could expect this is a large burden
drmirror 9y ago
The short answer is: just do it. You can add any field to any document at any time. That's the beauty of JSON documents without schema constraints. Then of course you need to let your application understand that. But it turns out it's almost trivial to make an application display a phone number field if it finds one, and not display a phone number if there isn't one in the document.
- mustardo 9y ago
  This is true It hurts when the next requirement comes along something like... "As a user I want to have a home, work, and mobile phone number" Now you have 3 "versions" of your implicit "schema" to contend with 1) No phoneNumber 2) phoneNumber and mapping it into / out of one of the three phone numbers in the UI 3) objects with three properties homePhoneNumber, workPhoneNumber, mobilePhoneNumber etc Then the business comes up with "As a user I want to have arbitrary phone numbers that I can label" now the developers start to squeal RDBMS + SQL is no panacea but having DDL operations like the following (all probably syntactically invalid but you get the idea) out of the box is incredibly powerful. ALTER TABLE user RENAME COLUMN phone_number TO home_phone_number; ALTER TABLE user ADD COLUMN work_phone VARCHAR(32) NOT NULL; CREATE TABLE phone_number (id BIGINT NOT NULL, user_id BIGINT NOT NULL, name VARCHAR(64) NOT NULL, phone_number VARCHAR(32) NOT NULL); I have had reasonable success using MongoDB as a store of "things that happened" and will never change