5 ms·

Less relevant than ever? Do you not think that MDB's API is part of what makes it so fantastic?

mantap 7y ago
There are plenty of good ORMs for Postgres if that's what floats your boat, but the advantage of Postgres is you can always drop down to SQL.
- dominotw 7y ago
  > but the advantage of Postgres is you can always drop down to SQL. All the project i've worked on eventually devolved into a weird mess of part orm and part SQL.
  - goatinaboat 7y ago
    Would have been easier and cleaner just to go with SQL from the start. Sadly devs always think it will be different if they try a different ORM next project and we always end up in the same place.
    - nicolaslem 7y ago
      As a developer working on projects using both approaches, it would be hard for me to pick a clear winner. One key difference for less experienced developers is that ORMs are usually integrated for you as part of a bigger framework (Django, Rails...). This provides some guidelines to get started on a more or less sane way. On the other hand plain SQL usually relies directly on the database client (or a thin layer like SQLAlchemy core) that requires you to make many decisions about the architecture upfront. I feel that one needs to experiment a lot (and fail a bit) before getting this part right.
  - ris 7y ago
    A good ORM acknowledges this and allows that to happen gracefully, while still allowing the 90%+ of straightforward queries to use the less error prone higher abstractions of the ORM.
zbentley 7y ago
I'm not GP, but I don't know what about Mongo's API is fantastic, or, frankly, even good (and I like mongo fine as a database). It is overly verbose, and, without a good set of client utilities, feels more like writing instructions for a black box query planner than asking for data from a database. SQL is vastly superior.
- Too 7y ago
  Mongodb aggregation queries are far more intuitive and easy to explain to juniors than sql, because they run in the order you write them and don't need blog posts like https://jvns.ca/blog/2019/10/03/sql-queries-don-t-start-with-select/ https://jvns.ca/blog/2019/10/03/sql-queries-don-t-start-with... (just found this on front page on HN). Well, actually there is a query planner in between also but they run as-if they were executed in that order. Anyway. They also by default protect you from sql injections and are easier to construct programmatically because appending a step in the pipeline is literally just appending to a standard json array, without having to know the complete lexer and AST of SQL and all. On the other hand they do make you pretty tired of curly brackets :)
spamizbad 7y ago
I've worked with MongoDB for close to 7 years, from 2.2 all the way through 4.0. I would not call its API good. Its greatest asset IMO is its straight forward replication and the fact that if you know JavaScript you "know" its syntax (albeit none of its idiosyncrasies). It's shortcomings are its limited type system, verbose query semantics, expensive indexes, unsophisticated query planner and memory limitations that force it to spill over to disk far more often than your typical SQL database.
- tracker1 7y ago
  I wouldn't call mongo's replication that straight forward... you get redundancy/or sharding (iirc) and if you want both, you have to layer them... and managing a cluster isn't always great... When the azure apocalypse happened a few years ago, with up/down, the 3 replica node cluster I was running was so damaged, the nodes couldn't catch up when it finally came all the way back up... fortunately, it was all denormalized data sourced from an rdbms, so was able to rebuild the cluster. I could have dropped two of the nodes, re-created them and rebuilt from there, in the end the total re-creation was faster. It wasn't anything resembling straight forward at all and if it was the source of truth would have potentially been much, much worse.
zitterbewegung 7y ago
From my experience using a SQL database is much better than using MongoDB. I can choose from either a ORM or direct SQL and there are a ton of resources . When I used mongoDB there was a learning curve that wasn’t transferable. It was hard to figure out how to enable security features. I did find a good GUI to run ad hoc queries.
therealdrag0 7y ago
I do not like the Mongo query language. But Spring's "ORM" made mongo decent to work with. And RoboMongo is a pretty usable client. I also like how quick it is to start working without an explicit schema and how db/table/fields are automatically created when referenced.

There are plenty of good ORMs for Postgres if that's what floats your boat, but the advantage of Postgres is you can always drop down to SQL.

dominotw 7y ago
> but the advantage of Postgres is you can always drop down to SQL. All the project i've worked on eventually devolved into a weird mess of part orm and part SQL.
- goatinaboat 7y ago
  Would have been easier and cleaner just to go with SQL from the start. Sadly devs always think it will be different if they try a different ORM next project and we always end up in the same place.
  - nicolaslem 7y ago
    As a developer working on projects using both approaches, it would be hard for me to pick a clear winner. One key difference for less experienced developers is that ORMs are usually integrated for you as part of a bigger framework (Django, Rails...). This provides some guidelines to get started on a more or less sane way. On the other hand plain SQL usually relies directly on the database client (or a thin layer like SQLAlchemy core) that requires you to make many decisions about the architecture upfront. I feel that one needs to experiment a lot (and fail a bit) before getting this part right.
- ris 7y ago
  A good ORM acknowledges this and allows that to happen gracefully, while still allowing the 90%+ of straightforward queries to use the less error prone higher abstractions of the ORM.

zbentley 7y ago

I'm not GP, but I don't know what about Mongo's API is fantastic, or, frankly, even good (and I like mongo fine as a database). It is overly verbose, and, without a good set of client utilities, feels more like writing instructions for a black box query planner than asking for data from a database. SQL is vastly superior.

Too 7y ago
Mongodb aggregation queries are far more intuitive and easy to explain to juniors than sql, because they run in the order you write them and don't need blog posts like https://jvns.ca/blog/2019/10/03/sql-queries-don-t-start-with-select/ https://jvns.ca/blog/2019/10/03/sql-queries-don-t-start-with... (just found this on front page on HN). Well, actually there is a query planner in between also but they run as-if they were executed in that order. Anyway. They also by default protect you from sql injections and are easier to construct programmatically because appending a step in the pipeline is literally just appending to a standard json array, without having to know the complete lexer and AST of SQL and all. On the other hand they do make you pretty tired of curly brackets :)

spamizbad 7y ago

I've worked with MongoDB for close to 7 years, from 2.2 all the way through 4.0. I would not call its API good. Its greatest asset IMO is its straight forward replication and the fact that if you know JavaScript you "know" its syntax (albeit none of its idiosyncrasies). It's shortcomings are its limited type system, verbose query semantics, expensive indexes, unsophisticated query planner and memory limitations that force it to spill over to disk far more often than your typical SQL database.

tracker1 7y ago
I wouldn't call mongo's replication that straight forward... you get redundancy/or sharding (iirc) and if you want both, you have to layer them... and managing a cluster isn't always great... When the azure apocalypse happened a few years ago, with up/down, the 3 replica node cluster I was running was so damaged, the nodes couldn't catch up when it finally came all the way back up... fortunately, it was all denormalized data sourced from an rdbms, so was able to rebuild the cluster. I could have dropped two of the nodes, re-created them and rebuilt from there, in the end the total re-creation was faster. It wasn't anything resembling straight forward at all and if it was the source of truth would have potentially been much, much worse.

zitterbewegung 7y ago

From my experience using a SQL database is much better than using MongoDB. I can choose from either a ORM or direct SQL and there are a ton of resources . When I used mongoDB there was a learning curve that wasn’t transferable. It was hard to figure out how to enable security features. I did find a good GUI to run ad hoc queries.

therealdrag0 7y ago

I do not like the Mongo query language. But Spring's "ORM" made mongo decent to work with. And RoboMongo is a pretty usable client. I also like how quick it is to start working without an explicit schema and how db/table/fields are automatically created when referenced.