Discussion :

[grinder59]

Bonjour,

néophyte en SQLServer, je dois néanmoins travailler sur une table qui reçoit des exports d'une base de compta. Ma base compta et ma table export sont sur un serveur 2000 Server. Cette table unique comporte plus de 300 000 enregistrements et la plupart des champs sont des strings.

Je dispose d'un autre serveur pour héberger mes services web.

Pour travailler sur ma table d'export, j'avais pensé faire une connexion odbc en php, langage que je maitrise bien.

Le problème est que les temps de réponses sont hyper hyper long... Tellement long que je suis prêt à trouver utiliser un autre langage pour interfacer ma grosse table. Mais lequel ? Quel langage me permettrait d'afficher plus rapidement le résultat de mes requêtes sur 300 000 enr ? et sur quel serveur ? le serveur web ou le serveur SQL ?

Postulat de base : je ne peux évidemment travailler que sur le table d'exports et pas sur la base de compta elle même.

[benratti]

Il y a plusieurs chos à voir avant de penser à changer de langage. Car je ne pense pas que changer de langage soit necessairement la solution.

Il faut que tu arriver à localiser la source de la lenteur.

Pour cela :
- tes requetes sont elles optimisées ?
- tes tables sont elles indexés ?
- ton serveur est il suffisament puissant ( CPU + RAM ) pour herberger SQL Server ?
- Y a t il d'autres applis qui interrogent le serveur et qui peuvent ralentir le serveur ?
- Y a til des problèmes reseaux qui pourraient être à l'origine de la lenteur ?

Bref, il y a plein de chose. Je te conseilles d'essayer d'explorer toutes ces pistes avant de vouloir changer de langage.

[ZERS]

Bonjour,

j'ajoute que 300000 enr c'est que dalle. Sauf si tu as 400 colonnes en nvarchar(3000)...

T'es sur que c'est le serveur SQL qui est lent ? As-tu essayer de lancer la requete directement sur le serveur SQL via le Query Analyseur ?

Parce que si les packages qui transitent par le réseau sont énormes, ...

Et la performance ne dépend pas du language utilisé, mais de la conception du système...

[DonkeyMaster]

Il est vrai que 300 000 enregistrements, c'est pas mal, mais ce n'est pas impressionant.
Optimise tes requêtes. Peut-être même, écrit une vue, si tu as des choses compliquées. Perso, j'aime écrire des vues pour tout et pour rien, ça me permet de réfléchir moins.
Vérifie les index (crées-en d'autres). Tu es sûr que tu as besoin de tous tes champs en varchar? Essaye de les passer en int, bit, char, etc... Ne néglige pas char.
Essaie de traiter le plus d'informations possibles dans ta requête. Par exemple, on retrouve parfois des gens qui font genre "select * from table", puis "foreach (object[] objs in results){ if (objs[0] == "qqch") ... }" dans leur code.

Si vraiment c'est intenable, passe à d'autres SGBD. Il semblerait que MySQL est plus performant, mais tu y perdras des fonctionnalités.

Sache que finalement, le langage est bien la chose qui compte le moins.

[benratti]

Pour info, j'utilise SQL Server et de très nombreuses bases, avec de très nombreuses tables, et de très nombreux enregistrement. A coté des tes 300000 enregistrements sotn vraiment rien par rapport à mon serveur SQL. Et SQL Server tiens tres bien la route.

Tout ca pour dire que je ne pense pas que ce soit SQL Server qui soit en cause... mais plus la maniere dont tu geres tes bases.

Bref, verifies les différents points que l'on t'as dit.