Les migrations auto générées peuvent être problématiques en terme de performance.
Mais tu le dis toi-même : il faut faire des migrations (SQL ou python, peu importe). Et la structure des bases SQL assuré l'intégrité des données largement mieux que des migrations écrites à la main et garantes de l'intégrité et de la cohérence des données.
À l'époque j'avais regardé orientdb qui était séduisant notamment pour son approche orientée graphe, mais au final je suis resté sur Postgresql et ça répond à tous les besoins auxquels j'ai eu à faire face.
Les projets sur lesquels j'ai vu du Mongo ont migré sur des solutions SQL dès qu'il a fallu s'assurer de l'intégrité forte des données.
J'ai vu des projets utiliser efficacement du Redis (-valeur) voire Elastic search comme base.
Le principe de se définir en "non quelque chose" n'a pas de sens pour moi : une base orientée graphe ne réponds pas aux mêmes usages qu'une base orientée documents ou une clé valeur.
À mon sens (rôle d'architecte logiciel) le sujet des migrations est le dernier des arguments pour choisir une base NoSQL : l'intégrité et la cohérence des données doit être assurée dans une application pérenne, et SQL est le meilleur outil pour que ces qualités soient assurées (bien plus que la performance des ingénieurs qui vont écrire les migrations).
Dernier retour d'expérience : avec le JSON embarqué dans Postgresql, tu peux faire du requêtage spécifique du coup je n'ai pas en tête de cas de figure où Postgresql ne répondrait pas.
Note : tout ce que je dis ici n'intègre pas les problématiques de scalabilité mais uniquement les problématiques de stockage, requêtage, d'intégrité des données et de maintenabilité du code associé.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: PostgreSQL partout
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 4.
Les migrations auto générées peuvent être problématiques en terme de performance.
Mais tu le dis toi-même : il faut faire des migrations (SQL ou python, peu importe). Et la structure des bases SQL assuré l'intégrité des données largement mieux que des migrations écrites à la main et garantes de l'intégrité et de la cohérence des données.
À l'époque j'avais regardé orientdb qui était séduisant notamment pour son approche orientée graphe, mais au final je suis resté sur Postgresql et ça répond à tous les besoins auxquels j'ai eu à faire face.
Les projets sur lesquels j'ai vu du Mongo ont migré sur des solutions SQL dès qu'il a fallu s'assurer de l'intégrité forte des données.
J'ai vu des projets utiliser efficacement du Redis (-valeur) voire Elastic search comme base.
Le principe de se définir en "non quelque chose" n'a pas de sens pour moi : une base orientée graphe ne réponds pas aux mêmes usages qu'une base orientée documents ou une clé valeur.
À mon sens (rôle d'architecte logiciel) le sujet des migrations est le dernier des arguments pour choisir une base NoSQL : l'intégrité et la cohérence des données doit être assurée dans une application pérenne, et SQL est le meilleur outil pour que ces qualités soient assurées (bien plus que la performance des ingénieurs qui vont écrire les migrations).
Dernier retour d'expérience : avec le JSON embarqué dans Postgresql, tu peux faire du requêtage spécifique du coup je n'ai pas en tête de cas de figure où Postgresql ne répondrait pas.
Note : tout ce que je dis ici n'intègre pas les problématiques de scalabilité mais uniquement les problématiques de stockage, requêtage, d'intégrité des données et de maintenabilité du code associé.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo