Discussion :

[lio69]

Bonjour,

J'ai développé une application C# qui se connecte à ma base MySQL via les ODBC. Le traitement fonctionne mais j'ai un timeout qui me bloque pour les grosses requêtes.

Je veux laisser tomber la connexion ODBC et je vais lancer à partir de mon application un petit bat qui va exécuter les requêtes directement à partir de l'invite de commande Mysql.

Pour cela, j'ai besoin de trouver le répertoire bin du serveur mysql. Savez-vous comment mon application peut retrouver ce chemin? Une variable d'environement? une requete sql? ...?

L'application tourne sur plusieurs poste client qui sont tous sous windows. Par contre MySQL n'est pas toujours installé dans le même répertoire.

[CinePhil]

Je ne connais pas le détail mais je pense qu'il faut plutôt jouer sur les paramètres du serveur MySQL ou du serveur d'application pour augmenter le timeout.

Voir aussi si le traitement qui plante n'est pas dû à une mauvaise architecture de données, à une mauvaise indexation ou à une requête simplifiable. En principe, un SGBD est capable de répondre en une fraction de seconde ou en très peu de secondes, même en traitant plusieurs millions de lignes.

[lio69]

Merci pour votre réponse.

Le traitement bloque lorsque je rajoute un champ dans une table qui fait plusieurs millions de lignes. Pour rajouter ce champ, j'utilise une requete alter table toute simple. Je pense qu'elle n'est pas optimisable.

J'aurais bien aimé allonger le timeout, mais je n'arrive pas à trouver où il est défini.

J'ai une autre piste qui consiste à modifier mon mode de connexion à la BDD. Je travaille sur une application dotnet (C#) qui se connecte grace à la dll MySql.Data.dll qui doit être fournie par MySQL si je ne me trompe pas. Cette dll me convient bien et je l'utilise simplement connexion / requete / deconnexion.

Après pas mal de recherche, j'ai pensé à cette solution de l'invite de commande mysql. Ca marche mais je dois spécifier l'adresse de mon serveur en dur dans l'interface et ca me dérange un peu.

[CinePhil]

Sauf dans des cas particuliers, on ne touche pas dynamiquement à la structure des tables ! On modélise les données et une fois la BDD implantée, sa structure ne change que très rarement.
Pourquoi veux-tu ajouter une colonne ?
Le plus simple est de le faire directement sur le serveur en effet.

[lio69]

Je suis admin d'une base de données.
J'ai une base de données principale sur un serveur et j'ai plusieurs utilisateurs nomades qui ont une image partielle de la base de données.
Les utilisateurs nomades ne peuvent pas travailler en direct sur la base de données. L'application permet de mettre à jour la base principale et les bases nomades.

Pour offrir de nouveaux services, mon logiciel évolue et à besoin de rajouter des champs dans certaines tables. Cette opération n'est pas régulière mais se reproduira surement. N'ayant pas d'accès directes aux serveurs déportés, je dois effectuer cette opération à distance. Il y a trop de nomades pour envisager une connexion manuelle sur chaque poste.

J'ai trouvé une solution qui ne me convient pas pleinement mais qui fonctionne. Mon application peut trouver le modèle constructeur de la machine. Le chemin d'installation du serveur MySQL local est identique pour chaque type de machine. Tant que le chemin est identique pour toutes les machines d'un même modèle, je suis bon.

[gene69]

1. Je suis souvent de l'avis de CinePhil. Si tu as un nouveau besoin de ALTER TABLE c'est que tu t'es planté quelque part auparavant.
2. tu fais des vues pour désigner les tables que tu consultes le plus souvent, comme ça changement de structure des données = invisible tant qu'on fait de la lecture (en écriture tu utilises des procédures ). Avec des jointures à l'intérieur qui sont faite sur les index ya aucun problème de performance, au contraire;
3. tu utilises de nouvelles tables et tu places une clée étrangère vers la table "mère". Dans certains cas tu peux te retrouver avec une clé primaire qui est aussi clé étrangère, ya des trucs sympa en base de donnée. (CinéPhil pas taper). Le plus souvent une structure avec des clés étrangères simple permet de compacter la donnée (ie: si tu as des villes + des CP à ajouter par exemple... )

Du coup, plus besoin d'alter table. Create table suffit. Le plus beau dans la table c'est que si tu as 1 seule colonne à ajouter à une table de 10 M. lignes, attribut qui sera rempli 10% des fois, cette solution t'économise (10*10%=)9M * taille du champs octets.