Discussion :

[lolo le belge]

Bonjour,

J'ai une appli qui fonctionne avec plusieurs CDatabase. En gros un CDatabase sert à faire les select avec CRecordset, plusieurs CRecordset ouverts pour un CDatabase. Et un CDatabse sert à faire des update et insert au travers de ExecuteSQL du second CDatabase.

Les deux CDatabase sont ouverts vers la même base. La question que je me pose: ne serait-il pas plus intéressant d'avoir un seul CDatabase qui effectue "en même temps" le parcours des CRecordset et les ExecuteSQL?

Qu'en pensez-vous?

Merci.

[3DArchi]

Salut,
Dans le projet où j'avais bossé, on avait un CDatabase pour chaque connexion tapant dans les mêmes tables. Est-ce que c'est + intéressant ? Je ne sais pas. Par rapport à quel critère ?

[lolo le belge]

Salut,

Merci de ta réponse.

Je pense essentiellement par rapport à la gestion des ressources, des performances. J'ai "seulement" 2 CDatabase pour toute l'application. Un sert pour les CRecordset et l'autre pour les update/insert. Je passe une référence au CDatabase nécessaire à chaque méthode/fonctions. J'ouvre les 2 connexions à la db au démarrage de l'application et je les ferme à la sortie de l'application.

Ma question est finalement: dois-je passer à un seul CDatabase qui fait à la fois les select et les update/insert, pour des raisons de performances, gestion des ressources?
Un Open en début d'appli et un close en fin d'appli vous semble plus efficace plutôt que des suites d'open/close?

[PetitPapaNoël]

Salut,

C'est toute la question du mode connecté et du mode déconnecté. Travailler en mode déconnecté a l'avantage de limiter les risques de déconnexion intempestive, mais l'ouverture et la fermeture des connexions peut prendre du temps, surtout si les requêtes sont nombreuses.

En ce qui me concerne, j'ai adopté un mode mixte : je suis en mode déconnecté, sauf quand je sais que, sur une période très courte, j'ai de nombreuses requêtes à faire. Dans ce cas, je reste provisoirement en mode connecté.

[3DArchi]

Salut,
Je pense que c'est aussi à mettre en perspective avec qui va avoir accès à la database : une seule instance de ton application cliente ou éventuellement beaucoup de client ? Après, rien ne vaut un bench.

[lolo le belge]

Il n'y aura que quelques instances de l'application. Actuellement je suis en mode connecté et j'ai à plusieurs endroits des tests "IsOpen()" sur les 2 CDatabase. Si false je fais un nouveau "Open".

[3DArchi]

C'est vraiment critique en terme de perf ? As-tu fais un bench pour le vérifier ? Tu risques de mettre plus de temps à faire un truc et créer des bugs potentiels pour gagner quelques microsecondes sur une portion où le temps est consommé ailleurs. Par exemple si le nombre d'enregistrement lu/copié est très très gros, c'est ce fetch qui risque de te prendre plus de temps que les temps de connexion.
Vaut mieux faire un bench pour voir où tu consommes du temps avant de partir sur des optimisations de code qui fonctionne peut-être déjà.

[lolo le belge]

Non, pas de problème critique. C'est plus une question "conceptuelle" que je me pose à un moment où j'ai plus de "libertés". L'appli a dû être faite rapidement il y a un certain temps et comme maintenant l'activité est plus calme je retourne un peu dedans en me demandant ce que je pourrais faire pour améliorer.

MODE OPTIMISTE: ON
La "crise" a quelques avantages
MODE OPTIMISTE: OFF

[3DArchi]

A ce moment, je me poserais plus des questions d'architectures. Les abstractions sont elles les bonnes ? Les différents principes (LSP, ISP, OCP, SRP) sont-ils respectés ? Les pointeurs sont-ils correctement gérés (pointeurs intelligents) ? etc.

[lolo le belge]

Merci pour ces liens. Je vais aller voir ça...