Est-ce que tu peux nous préciser en quoi PostgreSQL serait "rigide" ?
En utilisant des bases SQL, on se retrouve à faire des scripts de migration à chaque fois qu'on veut changer la structure de données. On en fait régulièrement, au fur et à mesure de la compréhension du métier.
Je connaissais l'existence du type JSON dans PostgreSQL mais je ne voyais pas trop l'intérêt si c'est pour tout sérialiser dans du JSON pour retrouver la souplesse et en sacrifiant l'intérêt d'une base relationnelle. Apparemment, c'est plus puissant que je ne pensais, je note ça comme élément à évaluer.
On utilise déjà PostgreSQL sur certains services que l'on maintient. On en est content tant que le service bouge peu (ou que c'est une exigence client).
Avec toutes les solutions NoSQL tellement nombreuses, est-ce que le risque n'est pas d'avoir à changer à nouveau par la suite ?
Oui c'est un risque. Faire le tour des solutions présentes est une tentative de minimiser le risque d'erreur plutôt que juste prendre la première qui passe, la plus populaire, etc.
[^] # Re: PostgreSQL partout
Posté par srb (site web personnel) . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 2.
En utilisant des bases SQL, on se retrouve à faire des scripts de migration à chaque fois qu'on veut changer la structure de données. On en fait régulièrement, au fur et à mesure de la compréhension du métier.
Je connaissais l'existence du type JSON dans PostgreSQL mais je ne voyais pas trop l'intérêt si c'est pour tout sérialiser dans du JSON pour retrouver la souplesse et en sacrifiant l'intérêt d'une base relationnelle. Apparemment, c'est plus puissant que je ne pensais, je note ça comme élément à évaluer.
On utilise déjà PostgreSQL sur certains services que l'on maintient. On en est content tant que le service bouge peu (ou que c'est une exigence client).
Oui c'est un risque. Faire le tour des solutions présentes est une tentative de minimiser le risque d'erreur plutôt que juste prendre la première qui passe, la plus populaire, etc.