Re-bonjour Phil Rob
Voilà un modèle plus parlant
Pièce jointe 585354
Pièce jointe 585355
Bonne soirée
Version imprimable
Re-bonjour Phil Rob
Voilà un modèle plus parlant
Pièce jointe 585354
Pièce jointe 585355
Bonne soirée
Il s'agit d'une gestion des contacts dans les filiales d'une société. Cela n'a rien de plus parlant sauf si c'est cette gestion que tu veux faire.
Cette gestion répond aux questions suivantes :
- Un enregistrement de Filiale est-il en relation avec au moins 1 enregistrement de Contact ? => OUI (Il y a au moins un contact à la filiale, sauf si on gère aussi les filiales avec lesquelles nous ne communiquons jamais, peu probable)
- Un enregistrement de Filiale peut-il être en relation avec plusieurs enregistrements de Contact ? => OUI (Il peut y avoir plusieurs un contacts à la filiale, un à la compta, un au service commercial, ...)
- Un enregistrement de Contact est-il en relation avec au moins 1 enregistrement de Filiale ? => OUI (C'est le but de cette partie de gestion, on n'encode pas là quelqu'un qui n'est pas un contact dans la filiale, on n'encode pas le clarkiste sauf si on peut effectivement être en contact avec lui, peu probable)
- Un enregistrement de Contact peut-il être en relation avec plusieurs enregistrements de Filiale ? => NON (sauf s'il existe un contact itinérant qui représente plusieurs filiales, peu probable).
Pour la gestion que tu envisages, toi seul peut apporter les réponses à ces questions. Cette méthode des questions est la plus simple que je connaisse pour structurer correctement un DB. Et ce n'est qu'après qu'on peut définir les relations et contraintes d'intégrité référentielles. Il n'y a pas de solution universelle. Chacune dépend strictement de la gestion effectivement en place.
La définition des relations est secondaire à l'analyse. Cela peut se faire et comme je l'écrivais ce matin, c'est un garde-fou contre les mauvaises manipulations. Il est prudent de le faire mais pas obligatoire. Dans l'exemple que j'ai envoyé ce matin, je n'ai pas défini la relation ni les propriétés de jointure. Cela n'empêche nullement l'encodage et la gestion de l'information. Simplement, ma DB de ce matin réponds à un jeu de questions. Si tu changes les réponses, cela fera une autre DB.
Enfin, l'interface est absolument secondaire. Ce n'est pas l'interface qui détermine l'organisation des tables mais bien le contraire : les réponses faites aux questions induisent certains types de présentation des données et en interdisent d'autres. Dans l'exemple des contacts des filiales, le détail des contact est présenté dans une ListView ou un DataGridView. Cela aurait pu être aussi une cascade de ComboBox ou une batterie de ListBox. Mais ce serait bien moins confortable avec seulement des TextBox ou avec un TreeView, par exemple.
... :)
Bonjour Phil Rob
Désolé pour le modèle, mais le principe de mon projet sera plus ou moins identique
Un enregistrement de T_General est-il en relation avec au moins 1 enregistrement de T_Fichier ? => OUI
Un enregistrement de T_General peut-il être en relation avec plusieurs enregistrements de T_Fichier ? => OUI
Un enregistrement de T_Fichier est-il en relation avec au moins 1 enregistrement de T_General ? => OUI
Un enregistrement de T_Fichier peut-il être en relation avec plusieurs enregistrements de T_General ? => NON
Bonne journée
Ok, je te fais un exemple avec ce jeu de réponses dans la matinée et je te l'envoie ...
Bonne journée !
:D
Suite ...
Discussion du jeu de réponses :
Un enregistrement de T_General est-il en relation avec au moins 1 enregistrement de T_Fichier ? => OUI
On ne peut pas accepter un enregistrement dans T_General qui ne désigne pas un fichier.
Un enregistrement de T_General peut-il être en relation avec plusieurs enregistrements de T_Fichier ? => OUI
Un enregistrement donné de T_General peut référencer plusieurs fichiers (ils pourront être présentés dans une liste de fichiers UN SEUL enregistrement de T_General).
Un enregistrement de T_Fichier est-il en relation avec au moins 1 enregistrement de T_General ? => OUI
On ne peut enregistrer pas dans T_Fichier un fichier qui n'est pas aussitôt utilisé par T_General. Probablement qu'une réponse NON serait meilleure de sorte à pouvoir encoder des fichiers qui ne seront utilisés que plus tard.
Un enregistrement de T_Fichier peut-il être en relation avec plusieurs enregistrements de T_General ? => NON
Un fichier ne pourra pas être référencé plusieurs fois dans T_General.
Il est possible de répondre OUI à cette dernière question et cela donnera encore une autre DB dans laquelle un T_General pourra référencer plusieurs T_Fichier et un T_Fichier pourra être référencé dans plusieurs T_General. Cette situation existe par exemple dans la gestion des rues désservies par les facteurs : une rue est déservie par plusieurs facteur et un facteur dessert plusieurs rues.
Voici les tables créés et remplies (selon le jeu de réponses) :
Pièce jointe 585394
Préparation d'une requête test avec l'assistant d'accès :
Pièce jointe 585395
Je n'ai toujours pas défini les relations, contraintes d'intégrités, propriétés de jointure ...
Visualisation de la requête en SQL :
Pièce jointe 585396
Visualisation de la requête en SQL après ajout de la clause ORDER (le résultat est plus lisible, c'est celle-ci qui sera copiée en VB) :
Pièce jointe 585397
Le résultat de l'exécution :
Pièce jointe 585398
Et voila ...
Pour affiner davantage l'analyse, il serait bien que tu envoies un jeu de résultats (cela peut être écrit sous XLS) avec les noms des champs représentatifs de leur rôle et quelques données fictives mais plausibles. Il faudra sans doute répondre aussi à d'autres questions.
Bonne journée ...:D
Suite +++ ...
J'ai créé une DB sur base de réponses OUI à chacune des 4 questions.
En matière de listes, elle permet aussi bien de lister tous les T_Fichier liés à un T_General que tous les T_General liés à un T_Fichier. Elle est une "fusion" de ma DB d'hier et de celle de ce matin.
Il peut paraître formidable de pouvoir lire toutes les informations dans n'importe quel sens mais en pratique, cela ne se fait que lorsque c'est nécessaire. Pour deux entités (tables) de la DB, lorsqu'on ne peut en désigner une comme "maître" et l'autre comme "esclave" (lorsque chacune est "maître"), il faut créer une table intermédiaire entre les deux. Cela augment donc un peu le volume de la DB, mais aussi les temps de réponses et la complexité de la programmation. Si cela ne présentait pas ces inconvénients, nous placerions d'office une table intermédiaire entre chaque paire d'intités.
Voici donc le résultat de cette nouvelle expérimentation.
Le jeu de réponses :
Un enregistrement de T_General est-il en relation avec au moins 1 enregistrement de T_Fichier ? => OUI
Un enregistrement de T_General peut-il être en relation avec plusieurs enregistrements de T_Fichier ? => OUI
Un enregistrement de T_Fichier est-il en relation avec au moins 1 enregistrement de T_General ? => OUI
Un enregistrement de T_Fichier peut-il être en relation avec plusieurs enregistrements de T_General ? => OUI
Voici les tables créés et remplies (selon ce jeu de réponses) :
Pièce jointe 585424
Préparation de la requête General-Fichier l'assistant d'accès :
Pièce jointe 585425
Visualisation de la requête en SQL après ajout de la clause ORDER :
Pièce jointe 585426
Le résultat de l'exécution de cette requête :
Pièce jointe 585427
Préparation de la requête Fichier-General l'assistant d'accès :
Pièce jointe 585428
Visualisation de la requête en SQL après ajout de la clause ORDER :
Pièce jointe 585429
Le résultat de l'exécution de cette requête :
Pièce jointe 585430
A toutes fins utiles, je t'envoie les 3 DB : Pièce jointe 585434.
A bientôt ... :D
Bonjour Phil Rob
Merci pour ton exemple
entre temps j'ai commencer ma DB peux-tu y jeter un œil pour savoir si je suis sur le bon chemin
Merci
bonne soirée
Oui, je peux voir ta DB mais tu dois l'envoyer ou bien la déposer en Dropbox (au autre) et m'envoyer le lien par messagerie privée. Je dois pouvoir ouvrir la DB avec Access 2013, je n'ai pas de version plus récente.
Il faudra que tu m'expliques les contenus. Vois-tu, quand tu montres la gestion des contacts, je vois une table Adresse et une table Contact : je sais ce que signifient ces mots.
Mais quand tu parles de General et de Fichier pour ton projet, je ne sais de quoi il s'agit : je sais ce que tu entends par Fichier, mais je ne sais ce que sont ces fichiers et je ne sais pas ce qu'est un General.
La méthode des questions pour définir les relations est plus facile si on sait ce que sont réellement les entités évoquées.
... :D
Voilà mon fichier.
Je vais essayer d'expliquer mon idée :
J'ai la table T_GENERAL qui est la table principale dans laquelle j'ai les champs :
G_ID (Clé primaire)
G_TYPE ex: Astuce excel
G_NOM ex : une astuce sympa pour excel
G_DESCRIPTION
G_CODE
G_NOTE
G_REMARQUE
G_COMMENTAIRE
G_LIEN
G_FICHIER => devrait être en relation avec la table T_FICHIER permet d’insérer plusieurs enregistrement uniquement pour le G_ID en cours
G_IMAGE => devrait être en relation avec la table T_IMAGE permet d’insérer plusieurs enregistrement uniquement pour le G_ID en cours
Bonne soirée
Bonjour,
Désolé de n'avoir plus eu le temps de revenir sur le forum hier soir.
La description que tu envoies, avec des exemples de données, me semble déjà plus significative ... :D
Je n'ai pas encore ouvert la DB, mais j'ai déjà remarques et questions à propos de cette description.
G_Type : généralement, un type est une valeur choisie dans un ensemble fini (extensible mais fini, limité à une quantité largement inférieure aux nombres d'enregistrements de T_General).
Par exemple, pour les personnes, nous pouvons trouver : Marié, Veuf, Célibataire, Cohabitant. Cette liste est limitée et toutefois extensible (cohabitant n'existait pas il y a 30 ans, il a fallu l'ajouter).
Donc ma question : quels sont les types que tu envisages ?
G_Nom : L'exemple que tu donnes est constitué d'une phrase complète. Cela risque de compliquer une recherche sur le nom. Sans connaître exactement la phrase "une astuce sympa pour excel", j'ai peu de chance d'encoder ce qu'il faut pour obtenir l'enregistrement.
G_Code : ± même commentaire que pour G_Type. Peux-tu donner des exemples de valeurs ?
G_Note : ± même commentaire que pour G_Type. Peux-tu donner des exemples de valeurs ?
G_Lien : Peux-tu donner des exemples de valeurs ?
Enfin, peux-tu donner un nom à ta gestion ? (Gestion d'un catalogue de trucs informatiques, gestion d'une basse-cours, ...). En fait, le nom de la table T_General ne signifie rien. Il devrait rappeler le nom du principal ensemble d'informations de la gestion (TClient pour la fiche "Client" dans une gestion des clients) le nom de la gestion à laquelle elle participe. Bien sûr, il n'y a que toi qui accèdera au code et si tu sais ce que cela signifie, c'est bien. Mais peut-être auras-tu des difficultés si tu reviens sur l'application quelques années plus tard ... (et puis, pour le moment, moi aussi je dois entrer dans le développement).
Les explications que tu donnes pour G_Fichier et pour G_Image sont suffisantes (pour l'instant :D).
... :D
Bonjour Phil Rob
Voila un fichier avec des valeurs exemples.
J’espère que cela est claire.
Bonne fin de journée
Merci, je regarde ça ...
OK, je comprends ... :D)))
La table T_General devrait plutôt s'appeller T_AstuceProg ou T_GeneralProg
ou T_GeneralAstuce
Pour G_Type, est-il bien nécessaire de rappeler le mot puisque ce sera toujours un "Astuce de ...".
Si finalement ce G_Type ne sert qu'à désigner un langage ou plate-forme (VBNet, VB60, ASP, PHR, SQL, ...), tu pourrais t'en tenir à ces libellés de type qui, étant forcément limités en nombre, pourraient se retrouver dans une table T_Type.
Pour G_Nom, j'ai seulement une suggestion à faire. Il s'agit donc d'une phrase représentative du sujet traité. Rien à redire coté analyse mais à l'usage, tu auras intérêt de ne garder que des mots clés de la phrase grâce auxquels ton programme pourra rechercher les articles traitant ± de la même chose.
Par exemple, "Remplir combobox depuis un autre formulaire" pourrait être remplacé par "ComboBox et multi-Formulaire". Lors d'une recherche, le programme pourra sortir les astuces dont le nom contient ComboBox et/ou Formulaire.
Point de vue analyse, je dois savoir si les G_Type peuvent être stockés dans une table T_Type.
Si tu change le nom de T_General, autant le savoir tout de suite, ça dispensera de modifier la DB sur ce détail.
J'ai encore un peu de temps ce soir ...
Oui la table T_GENERAL pour etre appelée : T_ASTUCEPROG
Pour le G_TYPE oui une autre table pour l'utiliser avec une combobox contenant : (VBNEt, Astuce Excel, .....) avec possibilité de rajouter des rubriques par la suite via un autre formulaire sera bien.
Pour G_NOM je retiens ton exemple plus cour.
Bonne soirée
Bonsoir,
Ci-joint Pièce jointe 585622 qui contient la DB refaite et un fichier de "réflexions" sur la création de cette DB.
La DB contient les tables telles que définies dans ce fichier de réflexions avec un jeu de données encodées directement dans Access, ainsi qu'une requête qui sort toutes les données.
En VB, il n'est pas toujours utile de reproduire une requête aussi globale. Il sera parfois plus aisé de présenter un enregistrement de T_ASTUCE_PROG et de charger les listes de détails avec la sélection des T_FICHIER et T_IMAGE qui le concernent. Plusieurs possibilités existent. Le fichier de "réflexions" contient une idée d'organisation de l'application.
Dans la DB que tu as envoyé, les relations sont déjà définies. Cela empêche la modification de certains champs. C'est la raison pour laquelle je ne définis les relations dans la DB qu'un fois l'application terminée.
Cela me permet de faire les modifications de DB parfois nécessaires en cours de développement et cela m'oblige à une programmation rigoureuse : l'intégrité des données doit être assurée même en l'absence de relations et de contraintes.
La nomenclature que tu utilises peut poser des problèmes : tu reprends la 1ère lettre du nom de la table en début de chaque champs.
Ainsi, le champ type de la table T_TYPE devrait s'appeler T_TYPE, soit le même nom pour la table et pour un champ. C'est source de confusion.
Un autre problème surviendra si on ajoute une table dont le nom commence naturellement par la même lettre qu'une autre : le champ ID par exemple porta le même nom dans chacune. C'est pas interdit mais c'est aussi source de confusion.
Je rappelle le nom de la table pour chaque champ en ajoutant le nom de la table au nom du champ, sauf dans les cas où le nom du champ indique naturellement à quelle table il appartient.
Par exemple :
IdFichier : Id dans T_FICHIER
Fichier : Nom du fichier dans T_FICHIER
XIdAstuceFichier : Copie de l'Id de T_ASTUCEPROG dans T_FICHIER
J'ai donc supprimé les relations que tu avais définies (elles ne convenaient de toute façon pas) et j'ai modifié la DB selon mes remarques ci-dessus et selon les réflexions.
La DB est correctement organisée contenu de la description que tu as faite des données. Si tu commences le développement en VB, je te conseille de privilégier l'utilisation du DataAdapter et des DataTable plutôt que d'uiliser les DataReader.
Enfin, un dernier point d'organisation du programme, dès lors que tu programmes tout. Dans ce cas, perso, j'utilise le DataAdapter et je produis les affichages par affectation des DataSource et Bindings avec les DataTable chargés. On peut dans ce cas consulter toutes les données dans ce mode "déconnecté". Lorsqu'une modification (modif, ajout, suppression) doit être reportée sur la DB, je passe en connexion directe (mode connecté) pour faire immédiatement la mise à jour de la DB. En cas d'erreur, elle ne porte jamais que sur le dernier enregistrement montré à l'écran, facilement identifiable, facile à corriger.
Mais il existe beaucoup d'autres approches, presque autant que de programmeurs (là, j'exagère un pue ... :D).
Bon amusement ...
Bonjour,
Voici un projet de tests qui rempli un DGV avec toutes les données de la DB (comme la requête sous Access) : Pièce jointe 585662.
Si tu veux l'exécuter, n'oublie pas de changer la chaine de connexion selon ton système.
Si j'ai un peu de temps, je ferai le test suivant : remplir le DGV avec les astuces et des ListBox avec les fichiers et les images.
...
Pièce jointe 585663
Suite ...
Finalement, c'était rapide à faire, voici le projet avec de 2ème test : Pièce jointe 585675.
Vois cette vidéo en guise de mode d'emploi : https://www.dropbox.com/s/nmoi1i4vmy...tuces.mp4?dl=0
Bon amusement,
:D
Bonjour Phil Rob
Merci pour ton fichier, je vais analyser tout cela pour comprendre le fonctionnement.
Si je comprend bien se sont ces lignes qui font les requêtes entre les tables :
Et avec des DGV on peu aussi faire un double clic sur un enregistrement pour ouvrir un formulaire.Code:
2
3
4
En tout cas un tout grand merci
Je ne manquerais pas de t'informer de l'évolution du projet
Bonne soirée
Bonsoir,
Oui, c'est ce genre de requête qu'on appelle jointure. Une jointure n'est parfaitement correcte qu'avec des tables bien organisées. Si tu examines la requête que j'ai écrite dans Access, tu pourras constater dans le premier test, où j'envoie tout dans le DGV, que je fais seulement un copier-coller de la requête d'Acces en VB. Là, j'ai enlevé les noms de tables qui précèdent chaque nom de champ car ils ne sont pas nécessaires (quand les champs sont bien nommés).
Il s'agit donc dans cette façon de faire, d'une super astuce :D : réaliser et tester les requêtes difficiles dans Access et les copier-coller ensuite dans VB !
Dans le second test, je ne charge que le DGV, 2 ListBox (fichier et image) et un RichTextBox pour le code (qui peut être volumineux). Rien n'interdit d'ajouter d'autres composants pour afficher des données telles que Remarque, Commentaire, ..., ainsi qu'un ComboBox qui présenterait les noms des astuces de sorte à pouvoir en choisir plus facilement.
Tous les composants réagissent aux clics (éviter les double-clic) et on peut donc écrire les procédures événementielles qui font ce que tu veux, notamment ouvrir d'autres Forms. Peut-être ne faut-il pas abuser de cela non plus (avis personnel, d'autres diront le contraire ... :)).
A bientôt ... :D
Merci Phil Rob
Je reviendrai surement vers toi quand je devrai pouvoir ajouter des enregistrement dans le formulaire ou pour champs de recherche.
Bonne soirée
Bonjour Phil Rob
J'ai un petit soucis avec ton exemple
Dans le DGV du formulaire FDGVEtListes quand je clic sur l'entête pour tri et sur le champs vide j'ai une erreur comme quoi le NULL est interdit
Merci
