Barrapunto

Seriamente, el problema del NoSQL son las consultoras.

El SQL y el modelo relacional han sido vendidos hasta la saciedad y son lo mas. Es muy difícil hablar de concurso publico y proponer algo que no sea un SQL. Son muchos los casos en que te obligan a usar SQL, quieras o no.

El problema que tiene el SQL es que fue ideado para solucionar un tipo de problemas muy especifico. Basicamente gestion de modelos sencillos de tablas.
Por fortuna o desfortuna el SQL fue dotado del ACID, esto ha permitido que hasta el mas patoso pueda funcionar en sistemas distribuidos sin preocuparse. Por esto, y la "estandarizacion" para hacer backups lo han hecho muy popular.

Sinceramente, desde la aparicion de la OO no entiendo porque se siguio usando el SQL, no es aconsejable. (Servir sirve, igual que podriamos guardar los datos bit a bit) Sea para bien o para mal, muchas de las propiedades de la OO no tienen traduccion directa a tablas, empezando por el polimorfismo. Y por otro lado, la simple sobrecarga de utilizar el SQL baja el rendimiento drasticamente.

Asi que para 4 chapuzillas con tablas, el SQL ya sirve, y no hace falta montarse ORMs ni nada por el estilo. Y para cosas mas complicadas, mejor sera ir pensando en usar NoSQL. (Lastima que las consultoras no tengan el nivel suficiente para aprender algo nuevo)

Sea para bien o para mal, muchas de las propiedades de la OO no tienen traduccion directa a tablas, empezando por el polimorfismo.

Los ORM tratan de cubrir esa limitación.
Puedes tener una clase Pato y una clase Tigre , que son subtipos de Animal.

El objeto Pato se guarda en una tabla ANIMAL y una tabla PATO, donde PATO tiene una FK a ANIMAL

El objeto Tigre se guarda en una tabla ANIMAL y una tabla TIGRE, donde TIGRE tiene una FK a ANIMAL

Cuando un ORM cargue los datos de PATO, cargará lo de ANIMAL y lo de PATO, y el objeto en el que es mapeado hará el polimorfismo ( por código ).
Por ejemplo, el método vuela() , heredado de la clase Animal, sería implementado en la clase Pato como "return true"