Quel cache ?
Ma phrase aurait pu être plus claire, je faisais référence à un cache que tu ferrais toi même avec une hash table ou équivalent, c'est à dire un cache local à l'application.
Concernant le profiling, c'est un peu plus gris, en Java je vais préférer que tout soit dans une même JVM pour avoir une vision globale et juste (historique des threads et lock dans JProfiler par exemple).
Pour la fragmentation, au contraire, plus l'espace mémoire disponible est grand, moins elle est un problème puisque mécaniquement les espaces contigus libre sont importants.
"faux problème"
Ce n'était pas de la rhétorique, je trouvais arbitraire de définir cela comme un problème, d'où mon explication du pourquoi ça ne pose pas de problèmes.
Pour les statistiques NoSQL que tu présentes, se pose en effet la question de savoir si le nombre de drivers est lié à la simplicité du protocole.
Autre réflexion :
plus une base de données est populaire,
plus le nombre d'utilisateurs est grand,
plus le nombre d'utilisateurs de langages peu utilisés est important,
plus la probabilité qu'un développeur/utilisateur se colle à la création du driver est importante.
Encore une fois, écrire un driver pour un protocole binaire n'a rien de difficile (par rapport à un protocole ascii) si le protocole est documenté.
De plus tu n'as (quasiment) jamais à le faire car les principaux langages ont tous leurs drivers officiels.
J'avais envie de te dire que le fait que le driver VB n'existe pas pour MongoDB, n'est un manque pour personne, mais en fait, ce driver existe (https://consulity.net/content/consulity-InstallMongoDB.aspx), idem pour Cassandra. Les chiffres sont donc à ajuster.
De plus, sachant qu'il n'y a pas de driver pour COBOL pour ces bases NoSQL, quelle corrélation y vois tu?
[^] # Re: Formatage automatique
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
Concernant le profiling, c'est un peu plus gris, en Java je vais préférer que tout soit dans une même JVM pour avoir une vision globale et juste (historique des threads et lock dans JProfiler par exemple).
Pour la fragmentation, au contraire, plus l'espace mémoire disponible est grand, moins elle est un problème puisque mécaniquement les espaces contigus libre sont importants.
Pour les statistiques NoSQL que tu présentes, se pose en effet la question de savoir si le nombre de drivers est lié à la simplicité du protocole.
Autre réflexion :
plus une base de données est populaire,
plus le nombre d'utilisateurs est grand,
plus le nombre d'utilisateurs de langages peu utilisés est important,
plus la probabilité qu'un développeur/utilisateur se colle à la création du driver est importante.
Encore une fois, écrire un driver pour un protocole binaire n'a rien de difficile (par rapport à un protocole ascii) si le protocole est documenté.
De plus tu n'as (quasiment) jamais à le faire car les principaux langages ont tous leurs drivers officiels.
J'avais envie de te dire que le fait que le driver VB n'existe pas pour MongoDB, n'est un manque pour personne, mais en fait, ce driver existe (https://consulity.net/content/consulity-InstallMongoDB.aspx), idem pour Cassandra. Les chiffres sont donc à ajuster.
De plus, sachant qu'il n'y a pas de driver pour COBOL pour ces bases NoSQL, quelle corrélation y vois tu?