Discussion :

[BasicZX81]

Bonjour à tous,
J'ai vraiment besoin de votre aide devant ce problème que je ne comprends pas du tout.
J'ai un formulaire pour éditer chaque ligne d'un DataTable à partir de Bindingsource.current.
Je valide mes changements par un BindingSource.EndEdit.

Cela fonctionne sans problème lorsque j'édite les colonnes autres que la colonne CLIENT qui est ma clé primaire.
Lorsque je veux modifier la valeur de ma colonne CLIENT, j'obtiens des erreurs dans le cas suivants :
- Si j'édite celle-ci avec une valeur qui ne modifie pas l'ordre de tri sur ma colonne CLIENT (l'ordre de tri pouvant être observé dans mon DataGridView), dans ce cas je n'ai pas d'erreur.
- Si j'édite celle-ci avec une valeur qui modifie l'ordre de tri, je n'obtiens pas d'erreur la première fois mais la deuxième fois j'obtiens le message d'erreur citée dans le titre.

J'espère que vous pourrez m'aider. En vous remerciant d'avance.

[Pol63]

une clé primaire n'est pas fait pour être modifiée, c'est une des principales règles sur les bases de données
ca ne doit pas non plus être représentatif pour l'application (= pas une donnée affichée à l'utilisateur)
ca sert juste à identifier une ligne de manière unique, et à faire les liens entre les tables
idéalement c'est aussi une colonne auto incrément

[tomlev]

Tout à fait d'accord avec Pol63, une clé primaire n'a pas à être modifiée. Si tu as besoin de la modifier, alors ça ne doit pas être ta clé primaire. Crée une nouvelle colonne (nombre auto incrémenté par exemple) et définit la comme clé primaire à la place de la clé actuelle.

[BasicZX81]

Bonjour et merci de m'avoir répondu.
Ma colonne ID représente (entre autres) des noms de client et sur le coup ca me semblait evident de définir ma clé Primaire sur cette information puisque le nom du client doit être unique.
- Savez vous comment faire simplement pour que le nom du client reste unique si je définie ma clé Primaire en tant que colonne auto-incrémentée ?
- Ensuite dans mon code j'utilise la méthode Find de l'objet DataTable pour atteindre mon enregistrement Client depuis une autre table (qui affiche le nom du client et pas l'ID), cette méthode ne recherche que les clés Primaire. (Pensez vous que je dois ajouter l'information de colonne ID dans ma deuxieme table pour pouvoir faire fonctionner ma méthode Find ? j'aimerais éviter si on peux faire autrement). (Je précise qu'il ne s'agit pas du relation un à plusieurs, je peux trés bien laisser le champs 'Nom du Client' vide dans ma deuxieme table).

Merci pour vos précisieuses informations.

[Pol63]

tu peux ajouter un index unique sur la colonne nom sur la base de données, en cas de tentative de doublon ca génèrera une erreur

en principe sur une base de données, il y a un id auto incrément par table, et c'est cet clé qu'on utilise dans les autres tables pour faire la liaison
car si le nom du client est modifié, il faudrait alors le changer dans toutes les tables où il est utilisé, ce qui niveau performance est loin d'être le mieux
avec une clé qui ne change pas il n'y a pas de soucis

[BasicZX81]

Merci pour la réponse Pol63,
Je crois que j'ai compris le principe.
J'espère ne pas abuser en posant une derniere question, est t'il contre indiqué de conserver mes colonnes 'Non du Client' dans mes tables enfants en plus de la nouvelle colonne que je doit rajouter portant l'ID de ma table parent ?
Je dit ca parce que je sait d'avance que j'ai besoin d'afficher le nom du client à partir de ces tables et que ca m'évite d'écrire des routines pour rechercher l'information dans la table parent.

[Pol63]

tu pourrais, mais ce n'est pas une bonne pratique pour plusieurs raisons
tout d'abord en cas de modification du nom, il faudrait aller modifier le nom dans les tables enfants = perte de performances
ensuite ca fait de la redondance inutile, normalement on fait des jointures pour afficher les infos d'autres tables (voir inner join et autres)
pour les jointures le mieux est d'avoir un index sur la clé étrangère

si depuis ton programme tu as toutes les données en ram, tu n'as pas besoin de jointure, un dictionary(of ) est pratique, ca permet de retrouver une instance par rapport à sa clé

[BasicZX81]

Merci et merci beaucoup pour ces informations Pol63,
je ne connaissais pas du tout les jointures mais j'ai trouvé des informations pour savoir comment cela fonctionne.
A priori pour répondre à ma problèmatique il faudrait que j'utilise une jointure RIGHT JOIN qui retourne tous les enregistrements de la table de droite (ma table enfants) peu importe la concordance entre les Id des 2 tables.

j'espère ne pas faire de bêtises et j'aurais encore trois autres questions :
1- Est ce que ma table de jointure va faire référence à mes tables simples, autrement dit est ce que si je modifie une donnée dans ma table de jointure cette modification va être répercutées dans ma table simple ?

2- Dans le même esprit je ne sais plus comment assurer l'enregistrement. Actuellement je charge chaque table issue de la base dans mon DataSet via une requette SQL classique : SELECT * FROM maTable. C'est cette même requette qui est utilisé par construire automatiquement les requettes de mises à jour, Delete , Insert et Update par le CommandBuilder. (J'aimerais éviter de modifier le code de chargement/enregistrements de ces tables dans la mesure du possible).
Faut t'il enregistrer les tables simples ou la jointures (et dans ce cas comment) ?

3- Par soucis de respecter les règles de bonnes pratique cette table doit t'elle être construite/chargé dans le Dataset comme les autres tables ou cette table doit t'elle être indépendante.

Désolé pour toutes ces questions mais je voudrais éviter de faire des mauvais choix au départ avant de me lancer dans une nouvelle restructuration.

En vous remerciant par avance.

[Pol63]

je ne suis pas expert en datatable dataset et autres dataadapter, mais je pense que oui ca tiendra compte de la jointure pour répercuter les modifications

enfin il faudrait un spécialiste datatable/dataset pour te dire comment faire au mieux pour le chargement et l'utilisation ...

(personnellement je préfère travailler avec des classes, des collections et sans commandbuilder ^^)

[tomlev]

je ne suis pas expert en datatable dataset et autres dataadapter, mais je pense que oui ca tiendra compte de la jointure pour répercuter les modifications

Ça ne fonctionnera pas avec le CommandBuilder, il faudra créer manuellement les UpdateCommand/InsertCommand/DeleteCommand

[BasicZX81]

Merci à vous pour vos réponses,
J'ai lu en effet sur un bouquin de programmation que le CommandBuilder ne sait gérer qu'une seule table.
Comme je ne suis pas à l'aise avec les requettes SQL j'ai un peu de mal à me passer du CommanBuilder , je préfere rester avec des tables simples pour l'instant, j'aurrais donc une colonne (une seule) 'Nom du Client' en doublon sur mes 2 tables avec un petit traitement en cas de modification du Nom (qui ne peux changer que depuis ma table Parent).
Je me lancerais peut-être si je suis plus à l'aise dans les jointures un peu plus tard.
En vous remerciant grandement pour vos conseils toujours bienvenus et trés judicieux.

[tomlev]

En fait je vois pas trop pourquoi il y aurait besoin de faire une jointure dans ce cas... Si c'est juste pour pouvoir récupérer le nom dans les tables enfant, il y a d'autres façons de faire. Le plus simple est de modéliser dans le DataSet les relations entre les tables ; on peut ensuite ajouter une colonne calculée (avec la propriété Expression) qui récupère les données voulues de la table parente. Tout ça sans faire le moindre JOIN en SQL...

[BasicZX81]

Si c'est juste pour pouvoir récupérer le nom dans les tables enfant

Oui, C'est juste ca que je veux faire. Ma table parent (Client) me sert à alimenter ma colonne de la table enfant à l'aide d'un Combox (lié). C'est donc juste l'information 'nom du client' que je récupére de ma table Parent vers la table Enfant.
Est ce que je dois toujours ajouter mes 2 colonnes ID connexes dans mes 2 tables ? et comment ajouter une colonne expression ?
J'en demande beaucoup ,désolé mais je ne maitrise pas (pas encore) cette partie.

[tomlev]

Côté DB :

- Dans la table Client, tu rajoutes l'Id comme discuté plus haut
- Dans la table enfant, qui faisait référence à Client par le nom, tu ajoutes une colonne ClientId ; c'est la clé étrangère, qui contient la valeur de clé primaire du client référencé
- Tu définis une contrainte de clé étrangère entre les 2 tables (pas obligatoire, mais recommandé pour l'intégrité des donnés)

Côté DataSet :

- Tu ajoutes les mêmes colonnes que dans la DB
- Tu sélectionnes les deux tables (client et enfant)
- Clic droit, ajouter une relation (ou un truc comme ça, j'ai plus la commande exacte en tête)
- Tu indiques quelle table est le parent de la relation (Client) et quelle est sa clé primaire (Id), quelle table est l'enfant de la relation (Enfant) et quel est la clé étrangère (ClientId)
- Tu donnes un nom à la relation (par exemple Client_Enfant)
- Dans Enfant, tu ajoutes une colonne NomClient de type String, et dans la propriété Expression tu tapes ça : Parent(Client_Enfant).Nom (en supposant que la colonne s'appelle Nom dans la table Client)


Et voilà, tu as maintenant une colonne NomClient dans ta table Enfant, qui ira automatiquement chercher sa valeur dans la table Client

[BasicZX81]

Bonjour et merci Tomlev,
Ta solution me plait beaucoup. Mon Dataset est construit par le code et pas en Design mais je pense que ça ne devrait pas poser de problèmes pour ajouter une colonne Expression.
j'en profite pour poser une dernière question (c'est la derniere promis..) :
A l'époque j'avais déjà mis en place une relation (entre mes colonnes connexes 'Nom de client') dans l'unique but de profiter des mises en jours en cascade (avec MaCléEtrangére.Update.Rule = Rule.cascade). Mais le fait de mettre en place cette relation m'obligé a renseigner le nom du client dans ma table enfants avec un nom de client existant dans ma table parent pour pouvoir créer un enregistrement. Autrement dit je ne pouvais pas créer un enregistrement avec un champ 'Non de Client' vide.
Est ce que j'ai loupé quelque chose ou c'est le fonctionnement normal de la relation. la mise en place d'une relation sur les colonnes Id pose le même problème je pense.

Si vous pouviez me confirmer, ça m'aiderais à faire les bons choix.

[Kropernic]

C'est normal.

Le but d'une relation est d'assurer "l'intégrité référentielle" des données.
Ce qui veut dire que la table enfant de la relation doit obligatoirement avoir dans sa colonne servant de clef étrangère une valeur se retrouvant dans la table parent.

Si on prend un exemple concret, ça devient tout de suite logigue.

Imaginons une table contenant des clients (T_CLIENT_CLI) et une table contenant des commandes (T_COMMANDE_CMD).

La table T_CLIENT_CLI aura comme colonnes les suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
- CLI_ID
 - CLI_NOM
 - CLI_PRENOM
 - ...(autres données éventuellement intéressantes)

où CLI_ID sera la clef primaire (cad que deux lignes n'auront jamais la même valeur pour cette colonne).

La table T_COMMANDE_CMD aura comme colonnes les suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
- CMD_ID
 - CLI_ID
 - CMD_DATE
 - ... (autres données éventuellement intéressantes)

où CMD_ID sera la clef primaire et CLI_ID une clef étrangère faisant référence à la colonne CLI_ID de la table T_CLIENT_CLI.

De cette manière, il ne sera pas possible d'insérer une ligne dans la table des commandes qui ne ferait référence à aucun client.
Et en pratique, cela se comprend. Pourquoi irait-on créer une commande qui n'aurait été passée par aucun client. Si une commande existe, c'est forcément que quelqu'un l'a demandée. On peut donc faire référence à cette personne.

Après vient le problème de savoir ce qu'il convient de faire lors de la suppression d'un client mais c'est un autre débat.

P.S. : Notez au passage le nom des objets. Une information se retrouvant dans plusieurs tables pour mettre en oeuvre l'intégrité référentielle (comme c'est le cas de notre exemple) devrait se trouver dans des colonnes ayant exactement les mêmes noms. Cela permet d'opérer des jointures naturelles.
Plus d'information sur les règles de nommages ici
Plus d'information sur les jointures ici

[Pol63]

une relation dans une base de données n'oblige pas forcément à ce qu'une valeur soit obligatoire
ca oblige que la valeur existe dans la table mère

par contre si la colonne autorise les null, ca ne pose pas de soucis d'y mettre null, il y a même des options de cascade "set null"

[Kropernic]

une relation dans une base de données n'oblige pas forcément à ce qu'une valeur soit obligatoire
ca oblige que la valeur existe dans la table mère

par contre si la colonne autorise les null, ca ne pose pas de soucis d'y mettre null, il y a même des options de cascade "set null"

Méa culpa, je me suis laissé emporté par l'exemple client-commande.

C'est vrai que si on a par exemple les tables T_HOMME_HOM et T_FEMME_FEM avec une référence à la première dans la seconde afin d'indiquer un éventuel mari, il faut avoir la possibilité que la femme soit célibataire et donc que la valeur soit null.

Il est aussi fréquemment conseillé lors d'une suppression dans la table parent de mettre la valeur dans les lignes des tables filles à NULL où à une valeur par défaut ne se retrouvant pas* dans la table parent pour procéder à la suppression "réelle" de manière différée. Comme expliqué ici (je l'avais lu dans un "vrai article" mais je ne le retrouve pas directement dans google)

*où à la valeur référençant une ligne fictive (par exemple un client bidon dont l'identifiant serait 0)

EDIT : J'ai finalement retrouvé l'arctile où il en est fait mention : lien vers l'article (il y en a certainement encore d'autres)

[BasicZX81]

Merci à tous pour votre aide c'est vraiment sympa,
Je vais mettre en pratique tous ça dès ce soir à commencer par le test sur les relations autorisants les valeurs null qu'il faut paramétrer sur les 2 colonnes CLIENT_ID des tables Parent et Enfant je présume.
J'ai au moins 3 paires de tables à rectifier sur ce principe mais ca devrait bien se passer avec toutes les infos que j'ai.

[Pol63]

une clé primaire ne peut être null
c'est sur les clés étrangères qu'il faudrait mettre nullable, enfin seulement si c'est possible dans ta modélisation des données
si un enfant doit forcément avoir un parent il faut laisser la colonne en non nullable