Ouais, ben c’est plus la mode on dirait #nosql
▻http://seenthis.net/tag/nosql
2010 : 8 mentions
2011 : 4
2012 : 4
2013 : 2
2014 : 1
2015 : 3
Je cherche une explication, parmi les millions qui existent, de quand utiliser #mongodb, et quand utiliser #postgresql.
J’en suis arrivé à la conclusion que mongodb est adapté pour des données simples, et très nombreuses, et postgresql pour un modèle de données complexe (beaucoup de relations entre beaucoup d’objets).
Qu’en dites-vous ?
pas vraiment compétent, mais de ce que j’ai compris pg est remonté au niveau de perfs des mongo et compagnie, ce qui fait que cet argument-ci n’est plus essentiel
par exemple ici ▻http://www.aptuz.com/blog/is-postgres-nosql-database-better-than-mongodb
le dernier lien parle de la version nosql de postgres, et pas de postgresql qui est une base relationnelle (enfin de ce que je comprends de la comparaison de départ de @severo)
@rastapopoulos je comprends de l’article que postgresql 9.4 intègre maintenant le type json, ce qui permet de stocker des documents de type json de la même manière que dans mongodb, et il est possible de mettre des contraintes, des clés, etc. sur les champs du json.
Mais il s’agit bien de postgresql, pas d’une version « nosql ».
Ouais en gros comme le champ « json » de Sphinx quoi. Et du coup ça veut dire que tu peux mélanger à la fois une base relationnelle classique, avec champs typés et définis en avance ET des tables avec un unique champ « json » dedans, complètement libre. Et même un mélange avec un objet contenant des champs bien typés ET un champ json totalement libre, dans la même table. L’avantage étant aussi de pouvoir faire tout ça avec le même logiciel, sans installer et maintenir deux moteurs différents.
