Barrapunto

Yo lo veo al reves, de lo que se abusa es del modelo relacional, el cual es inútil en el 99,9% de los casos.
Todo informático tiende a pensar que está haciendo la base de datos de un hospital o algo así y se lía a hacer integridad referencial, foreign keys, transacciones, triggers y no se cuantas mierdas mas ¿para el stock de una tienda de ultramarinos? ¿cual es la posibilidad de que se produzca una condición de carrera en un paki? luego viene el gato, tira el bote de tomate al suelo y te descuadra el stock.
Por no hablar de blog de internet, parece que es vital que si tengo 10678 fotos y 3856 mensajes, la suma de estos coincida exactamente con el numero que aparece, ni uno mas ni uno menos. Vamos por favor! ¡que no estáis programando una central nuclear.
Por muchas transacciones ACID distribuidas que inventeis vuestra vida será igual de miserable :)

Pues para una tienda ultramarinos me parece perfectamente lógico usar una base de datos relacional.

Las bases de datos relacionales añaden una capa sobre el acceso a los datos crudos, que no se limitan a integridad referencial. En lo que a mí respecta aporta dos cosas fundamentales: Transacciones y un lenguaje que en una sólo instrucción te permite sacar muchas cosas, que de otra manera las tendrías que sacar a mano.

Las bases de datos NoSQL renuncian a esa comodidad a cambio de hacer el programador las cosas a mano. Si la mayor parte del tratamiento es sobre una sola tabla, tiene peso, si no, pierdes más que ganas. O si tienes tal necesidad de velocidad que estás dispuesto a mejorar las optimizaciones que puede hacer el RDBMS.

Un programa de una tienda de ultramarinos es lo bastante complejo para merecer una base datos relacional. Te lo digo por experiencia. Hace muchos años hice el programa de una tienda en DBase, y no tiene color. Con SQL hace las cosas en dos patadas, con un lenguaje NoSQL, has de programarlo todo, más lento y más fácil hacer bugs. ¿para ganar qué?