Je souhaiterai juste pour le même "projet" (exemple 50 tables, 100 000 rows) avoir le temps d'accès lecture/écriture de MySQL / Oracle / PostGres etc... ainsi que la conso RAM/CPU par exemple.
La structure et la volumétrie d'une DB de test ne suffirait pas à interpréter les résultats des benchmarks. Ce sont des informations statiques, mais la façon dont la DB est utilisée dynamiquement compte énormément pour les performances. Par exemple, une DB utilisée pour de l'authentification ne présentera pas du tout le même profil de performance qu'une DB utilisée pour de l'achivage.
En matière de performances, il faut éviter les suppositions et mesurer. Autrement dit, si tu trouvais un benchmark du genre, il te renseignerait sur le cas particulier testé, sans vraiment te donner autre chose qu'une vague intuition sur ce qui se passerait dans ton cas.
Si tu travailles sur un nouveau projet, concentre toi sur ce qui compte vraiment : la modélisation de la structure de la DB (en visant la plus haute forme normale possible). Dans un premier temps, utiliser un connecteur type jdbc pour se connecter à un SGBD quelconque permet de travailler en SQL standard, ce qui permet ne pas trop investir dans un SGBD particulier et donc de ne pas avoir besoin de choisir un SGBD tout de suite. Une fois que le projet a un peu vécu, il est possible d'identifier les éventuels besoins en performances, et voir si c'est intéressant d'investir sur un SGBD et de passer à des APIs natives, voire commencer à utiliser des fonctionnalités spécifiques à un SGBD.
Bref,
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" - D. Knuth
[^] # Re: contexte ?
Posté par gaaaaaAab . En réponse au message Performances des SGBD. Évalué à 3.
La structure et la volumétrie d'une DB de test ne suffirait pas à interpréter les résultats des benchmarks. Ce sont des informations statiques, mais la façon dont la DB est utilisée dynamiquement compte énormément pour les performances. Par exemple, une DB utilisée pour de l'authentification ne présentera pas du tout le même profil de performance qu'une DB utilisée pour de l'achivage.
En matière de performances, il faut éviter les suppositions et mesurer. Autrement dit, si tu trouvais un benchmark du genre, il te renseignerait sur le cas particulier testé, sans vraiment te donner autre chose qu'une vague intuition sur ce qui se passerait dans ton cas.
Si tu travailles sur un nouveau projet, concentre toi sur ce qui compte vraiment : la modélisation de la structure de la DB (en visant la plus haute forme normale possible). Dans un premier temps, utiliser un connecteur type jdbc pour se connecter à un SGBD quelconque permet de travailler en SQL standard, ce qui permet ne pas trop investir dans un SGBD particulier et donc de ne pas avoir besoin de choisir un SGBD tout de suite. Une fois que le projet a un peu vécu, il est possible d'identifier les éventuels besoins en performances, et voir si c'est intéressant d'investir sur un SGBD et de passer à des APIs natives, voire commencer à utiliser des fonctionnalités spécifiques à un SGBD.
Bref,