SQL Server très lent comparé à Mysql ? [Résolu]

[berceker united]

Bonjour.
Actuellement, je suis en train de developper une application en php5 qui peut tourner sur Mysql5, 4 et SQLServer 2000. Et je constate qu'il y a une différence de temps d'execution.
Mysql5 > 0.05 seconde en moyenne
SQlServer 1.0 seconde en moyenne.
C'est une requête qui est appeler récurcivement avec une contrainte sur le champs sur SQLServer mais même quand je retire cette contrainte je trouve qu'il y a quand même une lenteur assez bizarre.
Pour 26 enregistrements je trouve que ça fait beaucoup. Je sais que Mysql est rapide mais Sqlserver me semble pas si lent quand je compare. L'appli est entierement objet et le processus pour executer une requête est la même.

Ma config
Athlon 3200+ venise 939
1go RAM.
Une carte mère Gigabite K8NSC-939
c'est pas assez ?

SQL Server
[idcategorie] [int] IDENTITY (1, 1) NOT NULL ,
[idcategorie_mere] [int] NULL ,
[idtraduction] [int] NULL ,
[ordre] [int] NOT NULL ,
[nom] [varchar] (50) COLLATE French_CI_AS NOT NULL ,
[description] [text] COLLATE French_CI_AS NULL ,
[date_crea] [datetime] NULL ,
[date_modif] [datetime] NULL ,
[actif] [bit] NOT NULL ,
[visible] [bit] NOT NULL

Mysql5
`idcategorie` mediumint(10) NOT NULL auto_increment ,
`idcategorie_mere` mediumint(10) NOT NULL default '0' ,
`idtraduction` mediumint(5) default '0' ,
`nom` varchar(255) NOT NULL ,
`description` text COMMENT,
`ordre` tinyint(3) NOT NULL default '0' ,
`date_crea` datetime NOT NULL,
`date_modif` datetime NOT NULL ,
`actif` tinyint(1) NOT NULL default '0' ,
`visible` tinyint(1) NOT NULL default '0',
PRIMARY KEY (`idcategorie`),
KEY `idtraduction` (`idtraduction`)


Quelqu'un aurait une éventuellement explication?
Merci

[SQLpro]

Et la requête ???

De plus vous n'avez mi aucune clef sur la table, donc aucun index !

Il faudrait au moins respecter les principes de bases de la modélisation de données, à savoir que toute table doit avoir une clef...

Des index aussi.

De quelle contrainte parlez-vous ?

Tout ceci n'est pas claireet révèle votre manque de connaissance sur le sujet (il est vrai que MySQL avec son pseudo SQL et sa manière de gérer les données se rapproche plus du cobol que d'un vrai SGBDR !)

A +

[TheLeadingEdge]

SQL Server
...
[actif] [bit] NOT NULL ,
[visible] [bit] NOT NULL

Mysql5
...
`visible` tinyint(1) NOT NULL default '0',
PRIMARY KEY (`idcategorie`),
KEY `idtraduction` (`idtraduction`)

C 1 peu pipé au départ non ?

[Alexandre T]

Je suis en train d'écrire un article sur les différentes méthodes d'accès aux données via PHP.
Je constate de légers écarts entre MySQL et MSSQL. Rien à voir avec ce que vous obtenez. (Je ne dis pas que l'un va plus vite qu'un autre, mes tests ne me garantissent pas actuellement que les deux processus se déroule dans les mêmes conditions environnementales). Mais si il y a avait des écarts de 2000% je les aurais remarqué !

En conclusion, de cet article, je conseille de privilégier l'accès aux bases de données via la nouvelle bibliothèque PDO de PHP.

Néanmoins, une bonne modélisation de votre base et une indexation adéquate, comme l'optimisation du serveur de données sont des points d'optimisation à ne jamais négliger !

[Alexandre T]

Envoyé par SQLpro

un vrai SGBDR !)

[Hors-sujet]Pourrait-on discuter à l'occasion de cette définition de SGBDR en privé ?[/Hors-Sujet]

[Marc Lussac]

Mysql est extrémement rapide pour les opérations simples

Ca n'est pas parce que c'est gratuit que c'est forcément plus lent

De plus, si vous utilisez mysql en mode non transactionnel (mode par défaut), parce que vous n'avez pas besoin des transactions (ca peu arriver), mysql est forcément beaucoup plus rapide que tous les autres SGBD qui sont tous en mode transactionnel par défaut

[berceker united]

Envoyé par SQLpro

Et la requête ???

De plus vous n'avez mi aucune clef sur la table, donc aucun index !

Il faudrait au moins respecter les principes de bases de la modélisation de données, à savoir que toute table doit avoir une clef...

Des index aussi.

De quelle contrainte parlez-vous ?

Tout ceci n'est pas claireet révèle votre manque de connaissance sur le sujet (il est vrai que MySQL avec son pseudo SQL et sa manière de gérer les données se rapproche plus du cobol que d'un vrai SGBDR !)

A +

Sur SqlServeur j'ai placé un index sur le champs idcategorie. Dans la génération du code de la structure j'ai peut être oublié de le faire mentionner.

La lecture de la table se fait de façon linière donc aucune clause. C'est qu'une requête très bateau SELECT * FROM categorie.
J'ai même placé la taille du cache de mysql à 0 .

[Luc Orient]

Envoyé par SQLpro

...
Tout ceci n'est pas claire et révèle votre manque de connaissance sur le sujet (il est vrai que MySQL avec son pseudo SQL et sa manière de gérer les données se rapproche plus du cobol que d'un vrai SGBDR !)

Ne dénigrez pas le COBOL SVP ...
Jamais il n'a eu la prétention d'être un SGBDR lui ...

[gregory.broissard]

Bonne remarque Luc

Le Cobol avec une base IMS, y a pas encore plus rapide pour traiter du volume de données.

Par rapport au sujet initial, je suis d'accord. Mysql est rapide mais c'est de la pseudo rapidité car effectivement il n'y a pas de transactionnel, etc.., etc... Il faut comparer ce qui est comparable. Mysql InnoDB / MSSQL peut être serait il plus intéressant. Maintenant, essayez de comparer les temps de mises à jour et d'ajout de données entre Mysql et MSSQL, et là ca fait mal à Mysql !

[berceker united]

ok j'étais bien au courant que Mysql était plus rapide que sql server mais dans mon cas pour si peut d'enregistrement et qu'il y ait une seconde pour le SQLsever ça me parait un peut abusé.