4 ms·

If you have a lot of relations in your data don't use mongo Why would you use Mongo if you have lots of relational data? Why would you not start with a rel

If you have a lot of relations in your data don't use mongo Why would you use Mongo if you have lots of relational data? Why would you not start with a relational database for that? I know Mongo has issues but it's never going to beat an RDBMS on relational queries.

jsemrau 10y ago
Because then you start moving your RDBMS logic in the application layer. And AFAIK, this is not the place for it.
lossolo 10y ago
It will never beat it in non relational queries also. To answer why - it was suggested by someone that said it's new modern db standard, that NOSQL is clear winner then showed me comparison on their site with SQL queries, all looked like it was substitution for RDBMS but it's not.
gleenn 10y ago
I think this is a common pitfall though: people start off thinking they don't really have relational data and then realize they actually do. Now they have a pile of code integrated with a DB that doesn't do relations well and can't be ported easily and then encounter cool bugs like this. No bueno.
lloyd-christmas 10y ago
We start our apps with mongo, and design them with a migration plan to postgres. We've found it's very easy to rapidly develop the application with mongo due to it's flexibility. Once we understand where or app is headed and what our relationships actually are, we pretty much pull the plug out of mongo and stick it in postgres. If you build a reasonably intelligent query wrapper it's fairly effortless. That being said, we're thinking of moving our early prototyping to Rethink now that it's made some strides.
- danneu 10y ago
  Meanwhile, normalized data is what gives me so much flexibility when using Postgres at the start of an app. I just store my data as generically as possible and usually all I need to change under churn is the queries. Denormalizing on day 1 (Mongo) has you making guesses about your data access patterns at the worst possible time instead of just thinking about the data itself.
  - lloyd-christmas 10y ago
    > Denormalizing on day 1 This has nothing to do with database choice. This is just shitty development. It's a strawman at best.
    - smadge 10y ago
      Can you explain what you mean? As far as I know, normalizing is a nonsensical process for a document store. You can only normalize a relational schema.
      - lloyd-christmas 10y ago
        > You can only normalize a relational schema. Normalization is just a method of organization to minimize repetition of data. It has nothing to do with efficiency of operation. This is perfectly valid code: person = { _id: "person123", username: "lloyd-christmas" } comment = { _id: "comment123", person: "person123", text: "This is how I start", } You don't have to do: person = { _id: "person123", username: "lloyd-christmas" } comment = { _id: "comment456", person: { _id: "person123", username: "lloyd-christmas" }, text: "This is also valid" }; Sure, a join is faster than the first one where you'll have to hit the DB twice. The point is that you don't have to START with denormalizing everything. I start with normalized data and do more DB reads than I need. I figure out how the application uses my data as I go along, and denormalize the pieces I need only once I need them and am confident I won't bump into consistency issues (my username isn't updating every 5 seconds). Through this process I realize what the actual relationships are in my application and how my app functions request to request. This allows me to better structure my data. This is a quick update in mongo and usually a couple of lines of refactoring in application logic. Obviously this is just an MCVE. My original point was that I find this to be a drastically more flexible process than starting off relational.

jsemrau 10y ago

Because then you start moving your RDBMS logic in the application layer. And AFAIK, this is not the place for it.

lossolo 10y ago

It will never beat it in non relational queries also. To answer why - it was suggested by someone that said it's new modern db standard, that NOSQL is clear winner then showed me comparison on their site with SQL queries, all looked like it was substitution for RDBMS but it's not.

gleenn 10y ago

I think this is a common pitfall though: people start off thinking they don't really have relational data and then realize they actually do. Now they have a pile of code integrated with a DB that doesn't do relations well and can't be ported easily and then encounter cool bugs like this. No bueno.

lloyd-christmas 10y ago

We start our apps with mongo, and design them with a migration plan to postgres. We've found it's very easy to rapidly develop the application with mongo due to it's flexibility. Once we understand where or app is headed and what our relationships actually are, we pretty much pull the plug out of mongo and stick it in postgres. If you build a reasonably intelligent query wrapper it's fairly effortless. That being said, we're thinking of moving our early prototyping to Rethink now that it's made some strides.

danneu 10y ago
Meanwhile, normalized data is what gives me so much flexibility when using Postgres at the start of an app. I just store my data as generically as possible and usually all I need to change under churn is the queries. Denormalizing on day 1 (Mongo) has you making guesses about your data access patterns at the worst possible time instead of just thinking about the data itself.
- lloyd-christmas 10y ago
  > Denormalizing on day 1 This has nothing to do with database choice. This is just shitty development. It's a strawman at best.
  - smadge 10y ago
    Can you explain what you mean? As far as I know, normalizing is a nonsensical process for a document store. You can only normalize a relational schema.
    - lloyd-christmas 10y ago
      > You can only normalize a relational schema. Normalization is just a method of organization to minimize repetition of data. It has nothing to do with efficiency of operation. This is perfectly valid code: person = { _id: "person123", username: "lloyd-christmas" } comment = { _id: "comment123", person: "person123", text: "This is how I start", } You don't have to do: person = { _id: "person123", username: "lloyd-christmas" } comment = { _id: "comment456", person: { _id: "person123", username: "lloyd-christmas" }, text: "This is also valid" }; Sure, a join is faster than the first one where you'll have to hit the DB twice. The point is that you don't have to START with denormalizing everything. I start with normalized data and do more DB reads than I need. I figure out how the application uses my data as I go along, and denormalize the pieces I need only once I need them and am confident I won't bump into consistency issues (my username isn't updating every 5 seconds). Through this process I realize what the actual relationships are in my application and how my app functions request to request. This allows me to better structure my data. This is a quick update in mongo and usually a couple of lines of refactoring in application logic. Obviously this is just an MCVE. My original point was that I find this to be a drastically more flexible process than starting off relational.