Re: Plan de test Clever Age

> Parceque tous les systèmes ont des points forts et des points faibles,
> et qu'on arrive facilement à faire dire ce qu'on veut aux tests, en
> tunant le hard, le soft... Bref...

C'est effectivement le point global à retenir de cette étude.

La societe choisit pour faire les tests n'ai pas plus à blamer que la
societe qui les a demande.
Dans ces tests entre aussi des paramètres de coup financier.

Il est évident que mettre en place un vrai logiciel exploitant les
possibilites des SGBDR (donc avec une émulation pour MySQL), serait bien
plus interessant en terme de visibilité mais aussi beaucoup plus complexe
à comprendre pour du grand public.
Mais ce type de test est particulièrement long et couteux et nécessite des
"experts" dans chaque BDD, avec un développement d'interfacage, etc etc.

Si je reprends mon exemple de logiciel de gestion de RH, si on
l'appliquait à une societe virtuelle de 300 000 personnes, on aurait des
différences importantes en termes de vitesses qui prendrait plus ou moins
en compte les aspects de lectures/ecritures de table, function, trigger,
etc etc.
Mais dans mon exemple, mise à part que la solution pourrait alors être
éditée/distribuée, pour un simple test, le coup serait totallement
prohibitif.
Je n'ai pas lu dans le premier mail que le magazine concerné allait faire
une étude très poussée des différents types de BDD client/server, mais que
c'etait juste un benchmark afin de donner une indication en therme de
performance pour le grand public.

Au final, l'oeil averti d'un administrateur ou d'un développeur saura
comprendre le benchmark avec ses points forts et ses faiblesses. Mais ceci
est autant vrai pour les SGBD(R) que pour toute comparaison entre deux
systèmes.

> Donc, c'est tout comme des benchmarks bidonnés comme celui là, je me
> demande "quel peut etre l'impact benefique" pour la revue qui l'édite.

Il n'y a pas de Benchmark bidonné. Il y a juste un banc de test qui a été
fixé. Quelqu'un qui cherche à développer mon exemple, ne se fiera pas
juste à un test sur la lecture/ecriture de deux tables, mais cherchera en
parallèle à se renseigner sur les possibilites de chaque BDD via le
net/newsgroup. La solution technique à long therme devenant primordial.

Je pense qu'il faut plutôt voir ce Benchmark comme une manière de
présenter au grand public que même si MySQL reste une des BDDs les plus
accessibles, des solutions comme Oracle ou DB ou MSQL ou PostgreSQL existe
et ceci à des coups pas forcément prohibitif.

Tout dépend de comment l'article va être rédigé. Je le rappel que la
société qui test les applications n'ai la que pour faire les tests
demandés et n'ai pas la pour juger qui est le meilleur.

> Complètement. On compare donc la chèvre et le choux. Et pourquoi ne font

> ils simplement pas un comparatif "qualité / Prix" ??
>
> Ou alors, un tableau tout bete avec une liste exhaustive de
> fonctionalités? Au moins on verait qui a quoi qui marche... Bien plus
> instructifs que des chiffres bidons.

CF au dessus, c'est à l'auteur de l'article et non a Clever Age de
stipuler ce type d'information.

> > Pour rappel, ce test est un test de bdd d'entree de gamme et non un
test
> > visant à faire un comparatif extremement poussé des differentes bdd
> > existantes sur le marché.
>
> « Entrée de gamme »? De quoi parlez-vous?

De ce qui a été demandé dans le premier mail :D.
Donc je dirais les bases données les plus faciles d'utilisations.
C'est pourquoi AS400 n'ai pas présent, ni les solutions Oracle haut de
gamme.
(On aurait pu mettre Notes aussi en faites)

> MySQL n'est pas un SGBDR. C'est un système de fichiers. Toutes les
> personnes qui essaient de faire de MySQL autre chose qu'un jouet avec
> qques tables, s'y cassent les dents.

A ce moment là, ils regarderont le test et migreront vers la solution
qu'ils considèrent la plus adapté à leur besoin dans la section SGBDR.

> > Mettons qu'une societe d'une 10e de personnes ayant une ressource
ayant
> > des connaissances informatiques veuillent mettre en place une base
type
> > RH de l'ensemble des employes.
> > Devront ils s'equiper de pgsql car il aura obtenu la meilleur note à
un
> > test ? Ou se contenter de MsAccess qui repondra LARGEMENT à leurs
> > besoins.
>
> Quitte à payer une fortune pour des outils bureautiques, pourquoi ne pas

> utiliser des SGBDR libres, largement plus performants, plus évolutifs,
> etc.. *et* gratuits?...

Pour deux raisons :
- Une majorité des PME/PMI ont un pack office (avec ou sans Access, avec
ou sans license) d'installer sur leur ordinateur. En conséquence, il tres
tres facil de developper un outil rapide et simple sans pour autant avoir
des connaissances pointus en informatique. Avec Access, on peut "tripoter"
des tables sans pour autant avoir la moindre connaissance du langage SQL.
- Le gratuit (/Libre), reste encore aujourd'hui quelque chose qui fait
peur et peu être associé à quelque chose fonctionnant mal/moins bien qu'un
logiciel possédant une license. Par ailleurs, un logiciel payant offre la
garenti d'avoir un service après vente (de bonne ou mauvaise qualité), et
cela rassure ENORMEMENT les dites PME/PMI. Si je prend pgsql, à moins de
passer par une société de prestation de service, il faut s'addresser sur
les forums, NGs, MLs, etc et la réponse peut parfois être très longue. Si
ma BDD crash pour une raison imputable au développement de pgsql, je peux
m'en prendre qu'à moi même, alors qu'avec un SAV, j'ai quelqu'un sur qui
taper. Ceci est nullement une critique, mais une constatation.

Résumé :
Je pense qu'il faut retenir que quelques points :
Le test s'adresse à du grand public et non un panel d'expert. Meme si vous
(personnes de la ML), estimez que MySQL est totallement dans
l'impossibilité de répondre à votre besoin (ce qui est aussi mon cas), le
test s'adresse à des personnes qui, de base, n'ont pas de vision de ce qui
existe sur le "marché" comparé à vous, qui avez DEJA étudié le sujet.
Il faut voir deux sociétés distinctes, une société qui va écrire un
article, et une qui s'occupe uniquement de la création des statistiques.
Ce n'ai pas la seconde qui sera déterminante dans la communication mais la
première. Par ailleurs, je ne crois pas que l'article se place en tant
qu'article exhaustif sur les différents BDD existantes.
Enfin, la société de test s'addresse à des personnes compétentes en la
matière pour l'aider à effectuer ses tests et met en avant une motivation
de ne pas laisser l'installation du serveur à des mains inexpertes.

froggy m'expliquait (le 16.07.2004 14:10):

> Au final, l'oeil averti d'un administrateur ou d'un développeur saura
> comprendre le benchmark avec ses points forts et ses faiblesses. Mais ceci
> est autant vrai pour les SGBD(R) que pour toute comparaison entre deux
> systèmes.

Le soucis principal dans ce que vous dites, est que ce n'est ni le
développeur, ni l'administrateur qui prennent la décision d'utiliser
telle ou telle plate-forme pour l'architecture à mettre en place. Ce
sont les DSI. Je prends une exemple : dans l'administration (celles qui
sont décentralisées du moins), les DSI ne sont pas forcément compétentes
en tout et vont se reposer énormément sur ce genre de tests. Dans ce
genre de contexte, qui plus est, rentrent en compte les différents
"rôles" qui sont fixés par la hiérarchie (l'administration étant un lieu
ou la hiérarchie et la politique peuvent -fortement- régner). Souvent,
les DSI n'aiment pas non plus qu'on prennent les décisions à leur place
ou qu'on convoitent leur poste. Mais là je m'éloigne et celà fait plus
partie de la sociologie que de l'informatique. Quoi qu'il en soit, du
côté fournisseur, c'est ce que l'on observe et on a droit, parfois à des
discours un peu gratinés, car "c'était dans le ZéroNain" ou encore "dans
le DMR". Je ne critique pas la presse non plus : je critique
l'ambivalence de certains discours et la mécompréhension de certains
points techniques. Bref, il faut être _trés_ précautionneux lorsqu'on
compare des produits et je pense que la levée de bouclier envers les
tests évoqués dans ce thread confirme l'analyse générale portée par une
partie, sinon l'ensemble, des intervenants de la liste (du moins ceux
qui se sont exprimés sur le sujet).

> Il n'y a pas de Benchmark bidonné. Il y a juste un banc de test qui a été
> fixé. Quelqu'un qui cherche à développer mon exemple, ne se fiera pas
> juste à un test sur la lecture/ecriture de deux tables, mais cherchera en
> parallèle à se renseigner sur les possibilites de chaque BDD via le
> net/newsgroup. La solution technique à long therme devenant primordial.

Pas si c'est un DSI justement. Un DSI cherchera peut être à faire faire
une étude par un groupe de travail éventuellement?! Mais parfois ce
n'est pas fait car celà coûte comme vous le disiez de l'argent et les
budgets peuvent ne pas être investis SI un article dans une revue de
référence fait office de test et qu'il y a mécompréhension. A terme,
celà peut être catastrophique.

> - Une majorité des PME/PMI ont un pack office (avec ou sans Access, avec
> ou sans license) d'installer sur leur ordinateur. En conséquence, il tres
> tres facil de developper un outil rapide et simple sans pour autant avoir
> des connaissances pointus en informatique. Avec Access, on peut "tripoter"
> des tables sans pour autant avoir la moindre connaissance du langage SQL.

Oui peut être, mais il ne faut pas confondre le front end et le
backend! On peut faire de l'access avec Postgresql en backend!

> - Le gratuit (/Libre), reste encore aujourd'hui quelque chose qui fait
> peur et peu être associé à quelque chose fonctionnant mal/moins bien qu'un
> logiciel possédant une license. Par ailleurs, un logiciel payant offre la
> garenti d'avoir un service après vente (de bonne ou mauvaise qualité), et
> cela rassure ENORMEMENT les dites PME/PMI. Si je prend pgsql, à moins de
> passer par une société de prestation de service, il faut s'addresser sur
> les forums, NGs, MLs, etc et la réponse peut parfois être très longue. Si
> ma BDD crash pour une raison imputable au développement de pgsql, je peux
> m'en prendre qu'à moi même, alors qu'avec un SAV, j'ai quelqu'un sur qui
> taper. Ceci est nullement une critique, mais une constatation.

Effectivement, la notion de responsabilité vis à vis d'un produit est
souvent une grande question dans les PME/PMI. La question est de savoir
si les gens sont prêts à prendre leur responsabilité plutot que de la
rejeter sur une société tiers.

--
Jean-Christophe Arnu
Paratronic

froggy wrote:

> Il est évident que mettre en place un vrai logiciel exploitant les
> possibilites des SGBDR (donc avec une émulation pour MySQL), serait bien
> plus interessant en terme de visibilité mais aussi beaucoup plus complexe
> à comprendre pour du grand public.
> Mais ce type de test est particulièrement long et couteux et nécessite des
> "experts" dans chaque BDD, avec un développement d'interfacage, etc etc.

n'oublions pas que lors de l'installation d'Oracle, on est amené à
approuver le fait qu'il est interdit de publier des benchmarks
comparatifs sans l'accord express d'Oracle. Je me suis laissé dire que
c'était pareil pour MS SQL Server (je ne connais pas). On voit bien que
par ce biais, Oracle verrouille la communication sur les performances
comparatives entre SGBD et que des tests défavorables, qui plus est
simplistes n'ont aucune chance d'être publiés.
Just my 2 cents.

--
Jean-Max Reymond
CKR Solutions
http://www.ckr-solutions.com