PC SOFT

PROFESSIONAL NEWSGROUPS
WINDEVWEBDEV and WINDEV Mobile

Home → WINDEV 2024 → Un ID unique dans une liaison serait recommandée mais pourquoi ?
Un ID unique dans une liaison serait recommandée mais pourquoi ?
Started by Jean-Michel, Feb., 13 2019 8:31 AM - 11 replies
Registered member
834 messages
Popularité : +13 (13 votes)
Posted on February, 13 2019 - 8:31 AM
Bonjour,
"On" vient de me dire la chose suivante :
Tous les fichiers doivent avoir un identifiant unique pour éviter des problèmes et le moteur HF en a besoin en interne.

Pour vous donner un exemple, voici 3 tables.
Pour une école, je note des élèves.

Table Matieres : Oui elle a un identifiant unique
Table Elèves : Oui elle a un identifiant unique
Et enfin une liaison Elèves / Matières pour y mettre la note. : Non, je n’ai pas besoin d’identifiant unique. C’est ma liaison entre les 2 fichiers.

MATIERES
------------
IDMatiere
Libelle

ELEVES
--------
IDEleve
Nom

MATIERESELEVES
IDMatiere (en doublon)
IDEleve (en doublon)
Clef composée IDMatiere + IDEleve (en doublon)
Note

On me dit de rajouter IDMatieresElèves Unique !

Rajouter cette clef unique me fait mal aux yeux.
Merci de votre retour concernant cette info.

J.Michel

--
Synchronize Systems International LTD
Développement d'outils de gestion

Environnements AS400 – Windows
Langages GAP III – CL – Visual Basic - Visual Adélia - Adélia - Windev

Bangkok / Pattaya
Registered member
108 messages
Popularité : +2 (2 votes)
Posted on February, 13 2019 - 9:35 AM
Bonjour Jean-Michel,

si tu peux saisir plusieurs notes de la même matière par élève et si c'est une clé unique, effectivement cela bloquera dès la saisie de la 2ème note de la même matière pour un même élève.

Mais il est vrai qu'un clé unique par fichier t'assure des doublons involontaires. Il te suffirait donc de rajouter une date dans ta clé pour qu'elle devienne unique.

Bon dev.

--
Cordialement

Philippe T.
Registered member
834 messages
Popularité : +13 (13 votes)
Posted on February, 13 2019 - 11:35 AM
Merci Philippe mais j'ai du mal m'exprimer.
Le Fichier MATIERESELEVES, si on suit Merise et la logique, n'a pas besoin de clef unique.
Pour en faire quoi !?
Cette relation permet de donner plusieurs notes à plusieurs élèves dans plusieurs matieres.

On m'a dit qu'une clef unique est nécessaire pour le moteur HF pour éviter d'éventuels problemes.
En ce qui me concerne, je m'interdis d'en mettre une pour respecter Merise et je n'ai jamais eu de souci dans mes fichiers de ce type.
Je suis très étonné de cette information et je cherche quelqu'un qui pourrait me valider que c'est vrai ou m'invalider.

Merci.

--
Synchronize Systems International LTD
Développement d'outils de gestion

Environnements AS400 – Windows
Langages GAP III – CL – Visual Basic - Visual Adélia - Adélia - Windev

Bangkok / Pattaya
Posted on February, 13 2019 - 12:08 PM
A mon humble avis :
- le moteur hf n'a pas besoin d'une clé unique
- mettre une clé unique dans une table de liaison, vis à vis de merise,
ça ne me choque pas, en merise chaque rubrique doit stocker une info et
une seule, "identifier uniquement un enregistrement" peut être vu comme
une info ^^
- mettre une clé unique, pour déboguer, je trouve cela pratique

Le fond du débat serait plutôt : travaille comme tu le sens ;)

eric l.

Le 13/02/2019 à 10:35, Jean-Michel a écrit :
Merci Philippe mais j'ai du mal m'exprimer.
Le Fichier MATIERESELEVES, si on suit Merise et la logique, n'a pas
besoin de clef unique.
Pour en faire quoi !?
Cette relation permet de donner plusieurs notes à plusieurs élèves dans
plusieurs matieres.

On m'a dit qu'une clef unique est nécessaire pour le moteur HF pour
éviter d'éventuels problemes.
En ce qui me concerne, je m'interdis d'en mettre une pour respecter
Merise et je n'ai jamais eu de souci dans mes fichiers de ce type.
Je suis très étonné de cette information et je cherche quelqu'un qui
pourrait me valider que c'est vrai ou m'invalider.

Merci.

--
Synchronize Systems International LTD
Développement d'outils de gestion

Environnements    AS400 – Windows
Langages                     GAP III – CL – Visual Basic - Visual
Adélia  - Adélia - Windev

Bangkok / Pattaya
Registered member
299 messages
Popularité : +16 (16 votes)
Posted on February, 13 2019 - 2:23 PM
Il y a des cas où je ne me pose pas de question.
C'est le cas des ID dans une table de base de données. On le met systématiquement on l'utilise pour appliquer des contraintes d'intégrité.

J'ai toujours travaillé de cette façon sous SQL Serveur, Oracle et même ACCESS. J'utilise peu HFSQL mais j'y appliquerai le même principe.
La règle est valable aussi pour les noms de champ dans une table. Par exemple un champ d'une table Client se préfixe CLI_ et s'appellera CLI_Nom, CLI_Prenom, etc...
Les noms de table suivent d'autres règles mais ce sont des automatismes et je rejoins tout à fait le 'on' du premier post.
Registered member
834 messages
Popularité : +13 (13 votes)
Posted on February, 13 2019 - 3:16 PM
Merci a tout le monde.
La réponse de Eric, je site : "Le fond du débat serait plutôt : travaille comme tu le sens" est génial ! C'est bien vrai !

--
Synchronize Systems International LTD
Développement d'outils de gestion

Environnements AS400 – Windows
Langages GAP III – CL – Visual Basic - Visual Adélia - Adélia - Windev

Bangkok / Pattaya
Posted on February, 13 2019 - 6:08 PM
Bonjour,
Personnellement, je mets systématiquement des ID Automatiques sur chacune de mes tables.

Très utile lorsque tu désires supprimer un enregistrement par son ID et que tu ne travailles pas en accès natif.

Cordialement,
Registered member
1,143 messages
Popularité : +50 (142 votes)
Posted on February, 13 2019 - 6:45 PM
Bonjour,

En fait la clé unique dans ton cas c'est une clé composée (avec doublon) elle permet juste à HFSQL C/S d'indexer mieux le contenu du fichier et d'accélérer la recherche dans la table ou l'exécution des requêtes. (je l'ai vérifié sur mes bases de données)
https://doc.pcsoft.fr/?3044178

Dans le même principe, une clé unique dans ce fichier améliore l'indexation par HFSQL, si tant est qu'on s'en serve dans les requêtes (genre ID<>null)... mais vue la simplicité de ta base de données je pense que ce ne serait pas plus utile que ça.
Posted on February, 15 2019 - 12:50 PM
Bonjour,

Normalement, toute base de données doit avoir un moyen d'identifier un enregistrement de façon unique. tu as le choix, tu peux soit utiliser une donnée (rubrique) que tu sais unique, soit une clé composée qui te permettra de distinguer un enregistrement plutôt qu'un autre depuis plusieurs données, soit un identifiant automatique si tu n'as pas d'autre moyen de rendre unique ton enregistrement.
Si d'un point de vu logiciel, cela te permet de parcourir plus vite ton fichier, d'un point de vue métier, cela te permets beaucoup de choses...
Prenons ton exemple, comment feras tu si tu veux effacer une ligne, par exemple Elève1 avec Matière1 a 2 notes 14 et 14. pour une raison quelconque, tu veux effacer une des 2 notes, comment vas tu programmer ça de façon simple?
Si on te demande une note parmi toutes les autres qu'est-ce qui te permet de savoir que c'est la bonne qui sortira avec ton programme.
Toujours dans ton exemple, tu pourrais ajouter une date à ta table de relation, de cette façon, le triplet (Élève, Matière, Date) te permet de distinguer chaque enregistrement de façon unique (si on considère qu'un élève ne peut pas avoir plus d'une note par jour et par matière) et t'éviteras donc de remonter des données de façon aléatoire. Et aussi tes règles d'intégrité te permette de t'assurer que tu n'a pas d'erreur (par exemple rentrer 2 notes à un élève pour la même matière à la même date).
Enfin si ta table de relation doit avoir une FK dans une autre table, cela ne sera possible que si tu as un identifiant unique dans cette première. D'ailleurs dans ce cas tu peux utiliser un ID auto si tu considère que l'utilisation d'une clé composée unique devient trop lourd (trop de rubrique à envoyer dans une autre table) à utiliser.

Je t'avoue que je n'arrive pas à considérer une table de BDD sans un identifiant unique comme du bon travail, mais comme l'a dit Eric, "travaille comme tu le sens"
Registered member
834 messages
Popularité : +13 (13 votes)
Posted on February, 15 2019 - 2:54 PM
,Patrick,
Concernant la suppression d’une des 2 notes dans ton exemple est un bon argument pour mettre une clef unique.
Je me suis mal exprimé.
Dans un autre exemple, si j’ai les fichiers suivants :

Diplomes
IDdiplome
Libellé

Employes
------------
IDEmploye
Nom

Dans la table Diplomes/ Employes je ne désire pas avoir 2 fois la même informations et ma clef unique sera la clef composée IDdiplome+ IDEmploye.
Je voulais dire, dans un cas comme celui la, on me dit de rajouter une rubrique avec clef unique (IDdiplomeEmploye) pour HF.
Et cette clef que je ne comprends pas pourquoi on me dit de la rajouter !

Désolé de ma mauvaise explication du départ.
Voila, voila…………

--
Synchronize Systems International LTD
Développement d'outils de gestion

Environnements AS400 – Windows
Langages GAP III – CL – Visual Basic - Visual Adélia - Adélia - Windev

Bangkok / Pattaya
Posted on February, 16 2019 - 12:18 AM
Tout à fait d'accord, si tu sais que la composition de tes 2 FK est unique, dans ton exemple un employé ne peut pas avoir 2 fois le même diplôme, un diplôme ne peut pas être attribué 2 fois à la même personne, alors un ID auto n'est pas du tout obligatoire.
Mais dans ton 1er exemple même si un élève n'a pas 2 fois la même matière et qu'une matière n'a pas 2 fois le même élève, la notion métier de note ne rend pas unique la composition de tes 2 FK, tu as donc le choix entre trouver une 3ème composante pour créer l'unicité (dans mon exemple d'avant la date) ou créer un ID auto.
Comme je l'ai dit avant tu pourrais juger utile d'avoir un ID auto si tu avais besoin d'envoyer une FK dans une autre table et que ta clé composé utilisé en PK commence à être lourde (trop de rubrique), à mon gout 3 c'est le max après ça devient chiant à coder, à ce moment là tu peux ajouter un ID auto pour éviter d'avoir à créer plus de 3 rubriques représentant ta FK dans ton autre table. Et c'est encore plus vrai dans le cas d'une relation en diamant.
Mais là tu devrais demander plus de justification à la personne qui te demande d'en mettre une...
Registered member
24 messages
Popularité : +1 (1 vote)
Posted on February, 16 2019 - 6:10 PM
Sujet intéressant. Effectivement j'ai 3 tables dans l'un de mes projets qui sont exactement dans ton cas et j'ai pourtant mis un ID Unique sur la dernière, en plus d'une clé composée unique elle aussi.

Pourquoi? Clairement par habitude. Chaque table, peut importe ce que je mettrais dedans, se voit attribuer une colonne avec un ID Auto unique. Question de principe chez moi. C'est surtout lié au fait que dans tous les codes sources Windev ou je suis passé (et je peux dire tous, car je ne suis pas bien vieux donc je n'ai pas vu des tonnes de projet encore), l'absence de cette ID m'a systématiquement posé problème lorsqu'il a fallu faire de la TMA ou apposer l'ORM maison que j'utilise pour abstractiser les accès à la BDD. Sans ID unique c'est un casse tête à gérer et en plus, ces projets avaient pourtant bien des ID uniques, mais des chaines...là j'ai saigné des yeux.

Au niveau des perfs, je ne pense pas que l'id unique soit utilisé par le moteur puisqu'il va certes identifier de manière unique l'enregistrement lui même mais au niveau métier c'est la clé composée qui lui sera utile. Mais, là, je voudrais bien l'avis d'un DBA..