Discussion :

[zakos_92]

Bonjour,

S'il vous plaît, j'aurai besoin de l'avis d'un expert.
J'ai créé une application Access, donc j'ai commencé par mes tables, ensuite les formulaires.....

Mais voilà, je n'ai créé aucune requête et à chaque fois que j'avais besoin de réaliser une opération compliquée, j'utilisais le vba avec les recordsets ...
Mais voilà, je suis tombé sur plusieurs applications de pro., et j'ai constaté qu'elles contenaient toutes des requêtes de sélection et de saisie.

Ma question est donc la suivante, en n'utilisant pas de requêtes est ce que mon application est digne d'un amateur, ou c'est seulement que j'ai mis plus de temps?
Enfin, je ne vois pas vraiment à quoi sert une requête si ce n'est pour là mettre en recordset, je voudrais donc si possible un récapitulatif (très concis, seulement quelques lignes ) des étapes pour la création d'une bonne application de pro.
Bizarrement je ne trouve de résumés simples nulle part.


J'espère que j'ai été claire, et je remercie beaucoup le courageux qui pourra m'éclairer.

Merci

[marot_r]

Bonjour.

Personnellement je ne juge pas le professionnalisme sur les techniques employées mais plus sur l'architecture générale de l'application et sa maintenabilité.

En gros, les questions qui m'intéressent sont :

• Puis-je facilement repérer les éléments constituants et les groupes d'éléments ?
• Puis-je facilement comprendre ce que cet élément fait ?
• Puis-je facilement modifier un élément SANS que cela ait de conséquences sur les autres ?

Ensuite les techniques employées dépendent généralement :

1. de ta formation. Moi aussi au début (je viens du COBOL et des systèmes de fichier indexés) j'avais tendance à faire les choses en VBA.
2. de la maîtrise (ou du sentiment de maîtrise) que tu as de la technique que tu utilises.
   En VBA tu as le contrôle total (ou presque) de ce qui se passe.
3. de tes goûts personnels.
   Personnellement je n'aime pas avoir du SQL dans mon code.
   Je préfère avoir mon SQL dans les requêtes et appeler mes requêtes depuis le code VBA.

Ensuite, pour les requêtes, la meilleur définition qui me vienne c'est que c'est un langage de spécification.
Tu n'expliques pas pas à pas ce que la machine doit faire, tu lui demande de s'en occuper pour toi.
C'est un peu la même différence qu'il y a à commander un repas au restaurant (SQL) par rapport à faire le même repas à la maison (VBA).

Avec une requête on peut :

1. Obtenir des données.
2. Modifier des données
3. Supprimer des données.
4. Ajouter des données.

Et c'est souvent plus rapide de faire cela en SQL que d'écrire le VBA correspondant.

Par exemple :

Vider entièrement une table en VBA va te prendre 5 à 6 instructions et un parcours en boucle de tes enregistrements.
En SQL tu écrira delete [TaTable].* from [TaTable]. Une seule instruction et une exécution quasi instantanée.

Pour remplir une table à partir d'une autre en VBA : Là encore tu vas devoir ouvrir les 2 tables puis transférer champ par champ, et enregistrement, les données de ta table source vers celle de destination. Sans doute une dizaine de lignes de code.
En SQL tu définis dans ta requête d'ajout la correspondance des champs (en passant par l'éditeur d'Access cela peut être un bête glisser/déplacer) puis après tu l'appelles et Access se charge de parcourir les données pour toi.

On peut aussi modifier la structure de la BD en SQL mais c'est plus avancé.

Note que SQL n'est pas un outil miracle, parfois un bout de code VBA est plus simple ou plus efficace.

A+

[zakos_92]

Merci beaucoup pour le temps que tu as pris pour répondre à mes questions.
Vraiment claire !!!

Ce qu'il me reste à faire est de m'y mettre.

Est ce que tu connaîtrais un tuto ou un livre résumant les différentes étapes de conception et de bonnes pratiques ?

Merci

[marot_r]

Est ce que tu connaîtrais un tuto ou un livre résumant les différentes étapes de conception et de bonnes pratiques ?

Non désolé, j'ai appris au cours des années et un peu partout.

Ceci dit, un très bon livre sur la programmation est Code Complete aux édition Microsoft, un peu daté mais toujours d'actualité. Je crois par contre qu'on ne le trouve plus en librairie mais peut-être en bibliothèque.
Et pour les BD j'ai suivi une session au CNAM sur la conception de base de données dans le cadre d'un diplôme d'ingénieur mais ils le donne peut-être à part.
Recherche aussi ce qui concerne la 3ième forme normale, c'est la modélisation recommandée pour les bases de données relationnelle. Celle qui te donne, à mon avis, le meilleur découpage de tes données en tables.

Et n'oublie pas la vertu première d'un informaticien : "être fainéant !".
Tu bosses très fort pour que la machine travaille pour toi ... et après tu la regarde faire et c'est vraiment gratifiant :-).

A+

[zakos_92]

Merci pour ta réponse.

C'est sympa à toi!

A+