4 ms·

Most of your points are ripe with folly. 1. ORMs are slow, but generally they are worth it, and it's trivial to dive into raw queries when needed for performan

by tinix 9y ago

Most of your points are ripe with folly. 1. ORMs are slow, but generally they are worth it, and it's trivial to dive into raw queries when needed for performance reasons. 2. Mongo supports relationships, not sure what you're trying to get at. Reverse delete rules are TRIVIAL to implement in your models. This is NOT the fault of the database engine, but fault of the developer, 100%. 3/4. Lack of normalization and schema is only a problem if you let it be. This is why model layers exist! If you are having to look "all over the code" to figure out the models, then the problem is you don't have any models. This problem isn't even limited to Mongo either, this can happen on a SQL-backed project too if the developer is an amateur. Not having a model layer is the fault of the developer (or architect), not to be blamed on the DB engine of choice.

winter_blue 9y ago
You should try to not start a comment with an attack. It just makes you look bad. See: http://www.paulgraham.com/disagree.html http://www.paulgraham.com/disagree.html Regarding your points: > 1. ORMs are slow Maybe you haven't used any recent ORM. Where did you get this idea from? In the JVM world, Hibernate is nearly dead for new projects. EBean[1] and JOOQ[2] are both great choice server-side Java/Kotlin/Scala projects. On Android / for SQLite, there's DBFlow[3], which I've used, and had great experiences. These ORMs are fast, intuitive, and powerful. Also relevant is: https://dzone.com/articles/martin-fowler-orm-hate https://dzone.com/articles/martin-fowler-orm-hate > 2. Mongo supports relationships Mongo's approach to relations[4] is far weaker and less powerful than what an RDBMS can handle. It was almost tacked on later as an afterthought. In addition, joins aren't a easy and straightforward with the kind of relations that NoSQL databases, like MongoDB support. > 3/4. Lack of normalization and schema is only a problem if you let it be. This is why model layers exist! NoSQL databases actively encourage de-normalization. For example, just take a look at this Firebase blog post[A] or see this page in their documentation[B]. It's almost sad and a shame that a company like Google is encouraging such poor ideas and practices; practices that they likely don't follow themselves (but I could be wrong). I know some young devs, who just graduating out of college, swoon all over databases like Firebase's. They read articles like these that say "schema-free" is cool, and denormalization is "normal". Ugh... I almost want to throw up. Model layers are optional. I recently worked at, and quickly quit, a (Fortune 500) company that used MongoDB, had an incredibly complex data model, and had no model layer or schema enforcement of any kind. Their codebase was thoroughly bug-ridden, and their heavily denormalized data had out-of-sync and stale copies all over the place. It was disgusting. [1] http://ebean-orm.github.io/ http://ebean-orm.github.io/ [2] https://www.jooq.org/ https://www.jooq.org/ [3] https://agrosner.gitbooks.io/dbflow/content/ https://agrosner.gitbooks.io/dbflow/content/ [4] https://stackoverflow.com/a/6994654 https://stackoverflow.com/a/6994654 [A] https://firebase.googleblog.com/2013/04/denormalizing-your-data-is-normal.html https://firebase.googleblog.com/2013/04/denormalizing-your-d... [B] https://firebase.google.com/docs/database/web/structure-data https://firebase.google.com/docs/database/web/structure-data
- tinix 9y ago
  None of your points are derogatory to MongoDB in particular, any more-so than any other database. Your points are wholly reflective of bad implementors and their implementations, not to the underlying technologies. If one misuses a tool, that's on them, not on the tool. Further, I think it's pretty fair to say: if it's as easy to mis-use something as it is to use it, then you have a very powerful tool that should be used carefully. If it's hard to mis-use something, then it's probably not a powerful tool. Basically, to use an analogy, don't use a jack-hammer to re-grout delicate tiles. A chisel and hammer work better, and you definitely wouldn't want to use a hammer and chisel to break up a concrete slab. Similarly, you wouldn't use a handheld rotary tool to cut a concrete slab, but using it to remove grout is perfect. Misuse of a tool leading to damage doesn't mean the tool is flawed, bad, or broken, it means it is being used incorrectly. Can you use it that way? Sure! Should you? Probably not. ORMS are indeed slower than straight SQL, period, always, 100% of the time. This is not opinion, but hard fact of simple logic. Generally speaking, it is rather silly to expect a complex abstraction to be faster, leaner, and more efficient than a lower level one. Adding more code and complexity will never make things execute faster. (Caching does not count, obviously, that's not the point here) That F500's total lack of effective systems architecture is the problem, not the database they used. This is like building a treehouse with nails driven at 90 degree angle, and then blaming the hammer when it falls apart. Totally, man, you definitely shouldn't have used screws, or driven your nails at an angle converse to the lines of force. Keep blaming your tools...

by tinix 9y ago

winter_blue 9y ago

You should try to not start a comment with an attack. It just makes you look bad. See: http://www.paulgraham.com/disagree.html http://www.paulgraham.com/disagree.html Regarding your points: > 1. ORMs are slow Maybe you haven't used any recent ORM. Where did you get this idea from? In the JVM world, Hibernate is nearly dead for new projects. EBean[1] and JOOQ[2] are both great choice server-side Java/Kotlin/Scala projects. On Android / for SQLite, there's DBFlow[3], which I've used, and had great experiences. These ORMs are fast, intuitive, and powerful. Also relevant is: https://dzone.com/articles/martin-fowler-orm-hate https://dzone.com/articles/martin-fowler-orm-hate > 2. Mongo supports relationships Mongo's approach to relations[4] is far weaker and less powerful than what an RDBMS can handle. It was almost tacked on later as an afterthought. In addition, joins aren't a easy and straightforward with the kind of relations that NoSQL databases, like MongoDB support. > 3/4. Lack of normalization and schema is only a problem if you let it be. This is why model layers exist! NoSQL databases actively encourage de-normalization. For example, just take a look at this Firebase blog post[A] or see this page in their documentation[B]. It's almost sad and a shame that a company like Google is encouraging such poor ideas and practices; practices that they likely don't follow themselves (but I could be wrong). I know some young devs, who just graduating out of college, swoon all over databases like Firebase's. They read articles like these that say "schema-free" is cool, and denormalization is "normal". Ugh... I almost want to throw up. Model layers are optional. I recently worked at, and quickly quit, a (Fortune 500) company that used MongoDB, had an incredibly complex data model, and had no model layer or schema enforcement of any kind. Their codebase was thoroughly bug-ridden, and their heavily denormalized data had out-of-sync and stale copies all over the place. It was disgusting. [1] http://ebean-orm.github.io/ http://ebean-orm.github.io/ [2] https://www.jooq.org/ https://www.jooq.org/ [3] https://agrosner.gitbooks.io/dbflow/content/ https://agrosner.gitbooks.io/dbflow/content/ [4] https://stackoverflow.com/a/6994654 https://stackoverflow.com/a/6994654 [A] https://firebase.googleblog.com/2013/04/denormalizing-your-data-is-normal.html https://firebase.googleblog.com/2013/04/denormalizing-your-d... [B] https://firebase.google.com/docs/database/web/structure-data https://firebase.google.com/docs/database/web/structure-data

tinix 9y ago
None of your points are derogatory to MongoDB in particular, any more-so than any other database. Your points are wholly reflective of bad implementors and their implementations, not to the underlying technologies. If one misuses a tool, that's on them, not on the tool. Further, I think it's pretty fair to say: if it's as easy to mis-use something as it is to use it, then you have a very powerful tool that should be used carefully. If it's hard to mis-use something, then it's probably not a powerful tool. Basically, to use an analogy, don't use a jack-hammer to re-grout delicate tiles. A chisel and hammer work better, and you definitely wouldn't want to use a hammer and chisel to break up a concrete slab. Similarly, you wouldn't use a handheld rotary tool to cut a concrete slab, but using it to remove grout is perfect. Misuse of a tool leading to damage doesn't mean the tool is flawed, bad, or broken, it means it is being used incorrectly. Can you use it that way? Sure! Should you? Probably not. ORMS are indeed slower than straight SQL, period, always, 100% of the time. This is not opinion, but hard fact of simple logic. Generally speaking, it is rather silly to expect a complex abstraction to be faster, leaner, and more efficient than a lower level one. Adding more code and complexity will never make things execute faster. (Caching does not count, obviously, that's not the point here) That F500's total lack of effective systems architecture is the problem, not the database they used. This is like building a treehouse with nails driven at 90 degree angle, and then blaming the hammer when it falls apart. Totally, man, you definitely shouldn't have used screws, or driven your nails at an angle converse to the lines of force. Keep blaming your tools...