En fait, si tu prends du PostgreSQL avec un champ de type JSON, tu as les même propriétés qu'avec une base SQL "classique" et le modèle générique en plus.
Tout ce que j'ai lu sur les bases NoSQL me laisse penser qu'on ne gagne pas en perf, le tunning pour avoir des perfs correctes étant un peu pointu, et aucune validation de modèle de données minimal (ce qui est possible avec PostgreSQL). Avec PostgreSQL tu peux en plus envisager d'implenter des fonctionnalités géographiques ; au final je ne vois pas l'intérêt de passer sur une base orientée documents.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Implémenter un modèle de données générique donc personnalisable.
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche pod : un outil de travail collaboratif pour suivre et gérer tâches, documents et autres. Évalué à 4.
En fait, si tu prends du PostgreSQL avec un champ de type JSON, tu as les même propriétés qu'avec une base SQL "classique" et le modèle générique en plus.
Tout ce que j'ai lu sur les bases NoSQL me laisse penser qu'on ne gagne pas en perf, le tunning pour avoir des perfs correctes étant un peu pointu, et aucune validation de modèle de données minimal (ce qui est possible avec PostgreSQL). Avec PostgreSQL tu peux en plus envisager d'implenter des fonctionnalités géographiques ; au final je ne vois pas l'intérêt de passer sur une base orientée documents.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo