5 ms·

mongo is easy to start with but it sure makes your project more complicated and painful as time goes on. it was to the point, i actually stopped enjoying work.

mongo is easy to start with but it sure makes your project more complicated and painful as time goes on. it was to the point, i actually stopped enjoying work. the power of sql is just too great to ignore, had gone through too many times where i wish i was on sql. i will probably use mongo for those times where i absolutely need to store a schema-less data (custom attributes), but will only do so in conjunction with a sql database. there is also that reliability and maintenance factor of securing it, making it redundant, and correcting problems when problem arises. all of which takes time off development. and just like OP, i probably won't ever start another project with mongo from ground up. there are just too much things to worry about and problems come out from all different angles when you least expect it. but in sql, everything just works.

camus 14y ago
impedance mismatch , that's why SQL is uber non sense in OOP architecture, especially when you end up using slow and buggy ORMs...
- deleted 14y ago
  [deleted]
- jeltz 14y ago
  The mismatch is quite bad between OOP and MongoDB too. A document database like MongoDB does not represent well recursive data structures or having different objects of different classes where any of them can be the entry point. MongoDB is good if your data is grouped into logical documents and is not an arbitrary object graph.
- meaty 14y ago
  If an ORM is slow or buggy, you're using it wrong or its crap. Most things that claim to be ORMs are really not very good quality. Try hibernate / nhibernate with ehcache cache backend. We find both to be an order of magnitude faster than hand tuned SQL and testable to boot.
  - mbell 14y ago
    I despise hibernate. I will never use a self managed 'session based' ORM again, it creates far too many messes.
    - meaty 14y ago
      When you get over the learning curve, which is quite large, the mess doesn't exist. I've never seen an issue with hibernate which isn't caused by poor understanding. You really do have to know your shit before you start - you can't just waltz in django-style and write code. You have to think about session management strategies and architecture.
      - mbell 14y ago
        It has nothing to do with understanding and everything with having to create a bunch of excess code to deal with the way it works. As an example: I shouldn't have to write a filter to wrap the template rendering stage of request processing in a transaction just to make lazy loading work. To make hibernate useful you almost always need to have another framework manage it (SEAM, Spring, etc). I'm not going to use an ORM that requires an entire other framework just to make it reasonable to work with. Hibernate also has the worst query building framework I've seen. Its far and away the most verbose piece of crap I've ever worked with. As a result most people just drop to writing queries in JPL which removes one of the big niceties of an ORM.
        meaty 14y ago
        Well you've conclusively proven my point because its obvious you don't know how to use hibernate properly. You never lazy load stuff from a view. That is a recipe for disaster. You use a projection or set of projections and populate your model up front. The transaction should be concluded way before the view is rendered. If you get that wrong, your architecture is broken. The only bit of infrastructure we use is an annotation + AOP which wraps a service method in a transaction and unit of work. This is all container managed. To be honest, it's literally 3 lines of config and works universally. Verbosity - that's a load of crap. We have 3 lines of AOP config, a mapping file per class and nh config which is about 12 lines of XML. All the config was cut and paste. The whole thing gives us a model which is portable between engines, proper transaction management, cache layer, schema generation, fully testable data API (we materialise the whole model into HSQL in integration tests) and documentation which is actually good. It's a no brainer. I suggest you go read POEAA and have a think.

camus 14y ago

impedance mismatch , that's why SQL is uber non sense in OOP architecture, especially when you end up using slow and buggy ORMs...

deleted 14y ago
[deleted]
jeltz 14y ago
The mismatch is quite bad between OOP and MongoDB too. A document database like MongoDB does not represent well recursive data structures or having different objects of different classes where any of them can be the entry point. MongoDB is good if your data is grouped into logical documents and is not an arbitrary object graph.
meaty 14y ago
If an ORM is slow or buggy, you're using it wrong or its crap. Most things that claim to be ORMs are really not very good quality. Try hibernate / nhibernate with ehcache cache backend. We find both to be an order of magnitude faster than hand tuned SQL and testable to boot.
- mbell 14y ago
  I despise hibernate. I will never use a self managed 'session based' ORM again, it creates far too many messes.
  - meaty 14y ago
    When you get over the learning curve, which is quite large, the mess doesn't exist. I've never seen an issue with hibernate which isn't caused by poor understanding. You really do have to know your shit before you start - you can't just waltz in django-style and write code. You have to think about session management strategies and architecture.
    - mbell 14y ago
      It has nothing to do with understanding and everything with having to create a bunch of excess code to deal with the way it works. As an example: I shouldn't have to write a filter to wrap the template rendering stage of request processing in a transaction just to make lazy loading work. To make hibernate useful you almost always need to have another framework manage it (SEAM, Spring, etc). I'm not going to use an ORM that requires an entire other framework just to make it reasonable to work with. Hibernate also has the worst query building framework I've seen. Its far and away the most verbose piece of crap I've ever worked with. As a result most people just drop to writing queries in JPL which removes one of the big niceties of an ORM.
      - meaty 14y ago
        Well you've conclusively proven my point because its obvious you don't know how to use hibernate properly. You never lazy load stuff from a view. That is a recipe for disaster. You use a projection or set of projections and populate your model up front. The transaction should be concluded way before the view is rendered. If you get that wrong, your architecture is broken. The only bit of infrastructure we use is an annotation + AOP which wraps a service method in a transaction and unit of work. This is all container managed. To be honest, it's literally 3 lines of config and works universally. Verbosity - that's a load of crap. We have 3 lines of AOP config, a mapping file per class and nh config which is about 12 lines of XML. All the config was cut and paste. The whole thing gives us a model which is portable between engines, proper transaction management, cache layer, schema generation, fully testable data API (we materialise the whole model into HSQL in integration tests) and documentation which is actually good. It's a no brainer. I suggest you go read POEAA and have a think.