Discussion :

[ilank]

Bonjour, Pierre,
il n'y a aucun jugement de valeurs dans mes propos. Je fais juste la distinction de logique, d'approche et les conséquences qu'elles s'entrainent sur une application Access, entre deux métiers différents appelés à créer des bases de données. Si tu as vu quelques jugements de valeur dans mes posts, je n'y peux rien.

Peut-être la convivialité et la facilité passent-elles par des boutons inactifs ou invisibles pour masquer les actions non souhaitées, mais y-a-t-il vraiment perte de l'une ou de l'autre avec un message d'erreur comme illustré plus haut? A cela, ilank semble répondre OUI et moi je réponds NON.

Ce n'est abosulement pas ce que je pense, j'ai simplement affirmé que le soucis de griser un bouton était typique du développeur, et qu'à mon avis on trouvera pas ce même soucis chez un dba; qui lui placera les contraintes avant tout sur les données et non pas principalement dans le code. Je n'ai rien dit de plus.
A aucun moment, je n'ai prétendu qu'il faut être l'un ou l'autre; mais qu'à partir du moment où l'on fait la distinction entre les deux on comprend mieux le contenu des posts de ce débat.

[Tofalu]

Bonjour à tous

Je rejoint l'avis de Pierre Fauconnier

L'intégrité référentielle ne devrait pas être une option mais une obligation en matière de base de données de production. Exception faite pour les tables temporaires, de paramétrage ou de traitement.

Pourquoi ?

Tout simplement que la seule chose qui a de valeur au sein d'une base de données c'est justement les données. Si le produit que vous avez développé à un coût, celui-ci n'est rien, comparé aux données qui y sont stockées et traitées. Le risque que tout un système soit paralysé, simplement parce qu'une erreur subite du code VBA a eu lieu et qu'un client se retrouve avec un numéro d'id 0 et que du coup on perde toutes ses données liées ne devrait pas avoir lieu.

Le Job, ce n'est pas que faire des interfaces kikoo joli et à celui qui "pissera de la ligne de code au plus loin" mais garantir à l'utilisateur que ses données seront traitées exactement comme il le souhaite et en sécurité.

De plus comme le rappel Pierre, le mécanisme étant directement intégré dans le moteur Jet, l'intégrité est valable quelque soit l'application qui attaque la base.
Et quel intérêt de coder ce qui a fait ses preuves et est bien plus fiable qu'un code qui s'exécute en annexe ?

Cette obligation me semble d'autant plus importante qu'il n'existe pas sous Access de trigger ni de procédure stockée.

Les relations sous Access avec intégrité référentielle, c'est donc :

- facilité de mise en place,
- confort
- accélération du temps de developpement
- sécurité
- cohérence, intégrité
- flexibilité
- portabilité

Alors effectivement, difficile de trouver une justification à ceux qui ne les utilisent pas ...

[LE VIEUX]

bonjour a tous,
et salut les experts.
une occasion soit de régler un problème que je n'ai peut-être pas assez approfondi soit de faire ressortir une limite gênante de l’intégrité référentielle.
Cela concerne l’utilisation des tables liées – elles peuvent être nombreuses dans des bases scindées.
Pour ma part j’utilise dans plusieurs bases une table liée d’une autre base dans laquelle je dois parfois enregistrer un champ « clé primaire », provisoire, je ne maitrise pas cette info dans l’immédiat.
A la mise a jour de la base, bien sur il faut identifier les champs à modifier, pas très grave car ils gardent la valeur de base, mais problème si l’on oublie.
Donc si je n’ai pas loupé une possibilité de gérer, l’intérêt mais aussi la limite de l’intégrité référentielle que j'utilise bien sur chaque fois que possible.
A vous les experts et merci de la solution.

[marot_r]

Je ne suis pas certain que j'ai compris ce que LE VIEUX dit mais on ne peut pas assurer l'intégrité référentielle entre 2 bases Access. On peut simplement établir des relations sans intégrité mais c'est déjà une excelente chose par rapport à pas de relation du tout.

Pour avoir été pris à essayer de remonter une intégrité référentielle à partir des tables, du code et des requête, je peux vous assurer que les avoir au départ c'est VRAIMENT une bonne chose.

A+

[LE VIEUX]

Bonsoir,
C’est vrai, marot_r en me relisant je constate que je n’étais pas très clair, j’ai fait vite est pas bien.
Mais cela confirme ce que « je voulais » faire ressortir – soit que sur une table liée on ne pouvait pas faire de relation avec intégrité référentielle, ce que tu confirmes –
Par contre mon texte n’étant pas clair, on peut interpréter que cela concerne les bases divisées, et ça c’est une connerie si les 2 tables sont dans la même base bien sûr. Mon problème se posait bien sur une table d’une base divisée par rapport à une relation voulue avec intégrité référentielle sur une table d’une autre base divisée ou pas.

J’en étais a peu près persuadé, sinon j’aurais posté – mais cette discussion intéressante m’a donné l’occasion de vérifier auprès d'expert.

Donc on s’en passera – et je suis bien d’accord avec toi et les autres sur son intérêt, et pour cause j’aurais bien aimé que cela marche aussi sur les tables liées à d’autres bases mais enfin cela parait évident de ne pas pouvoir lier des bases par nature indépendantes.
avec mes excuses pour ceux que j'ai embrouillés.

[ilank]

Bonjour à tous,

L'intégrité référentielle ne devrait pas être une option mais une obligation en matière de base de données de production.

Qui a prétendu le contraire ?

Exception faite pour les tables temporaires, de paramétrage ou de traitement.

Tiens,tiens. Il y a donc bien des scénarios pour lesquels l'intégrité référentielle n'est pas applicable.

Tout simplement que la seule chose qui a de valeur au sein d'une base de données c'est justement les données.

On est d'accord mais puisque on parle d'acccess, on fournit rarement une base seule mais également l'outil d'exploitation.

Si le produit que vous avez développé à un coût, celui-ci n'est rien, comparé aux données qui y sont stockées et traitées.

On pourrait être d'accord, toutefois je suis convaincu que tu n'as jamais livré une base vide de tous formulaires, et états.

Le risque que tout un système soit paralysé, simplement parce qu'une erreur subite du code VBA a eu lieu

????

et qu'un client se retrouve avec un numéro d'id 0 et que du coup on perde toutes ses données liées ne devrait pas avoir lieu.

Personnellement, je suis bien moins inquiet par un id 0 d'un client, que par une multiple nomination d'un même client. D'ailleurs, n'est-ce pas sur ce site que l'on trouve des outils de calcul de correspondance phonétique. L'intégrité référentielle n'y change rien.

Le Job, ce n'est pas que faire des interfaces kikoo joli et à celui qui "pissera de la ligne de code au plus loin" mais garantir à l'utilisateur que ses données seront traitées exactement comme il le souhaite et en sécurité.

L'utilisateur ne servira pas deux fois d'un outil cracra tout pas beau.
Livres-tu des bases accéssibles uniquement en ligne de commande sur écran 14 pouces texte vert sous fond noir ?
Vois par toi-même, on peut dire que les codes couleurs appliqués ici pour les lignes de code n'a que peu d'intérêt, pour ma part je suis convaincu que cela participe au succès du site.

[Heureux-oli]

Salut,

Donc, si j'en crois tes dire, tu es certain que ton code va se dérouler complètement et convenablement à chaque fois.
Tu ne commets donc aucune erreur et aucun oubli dans ton code !

Chapeau bas.

Des utilisateurs, j'en ai déjà vu de toutes les sortes et le simple fait de passer par l'intégrité référentielle fournie par Access est une sécurité et une grande facilité.

[cbleas]

Bonjour,
ne pas utiliser l'intégritée référentiel c'est ne pas avoir la sécurité qu'elle procure.
Pour ma part il m'arrive de ne pas pouvoir l'appliquer et là j'utilise le VBA mais avec les risques que ça implique c'est à dire de supprimer des données que je ne voudrais pas.
Aujourd hui ma base de donnée comporte plus de 400 Tables heuresement que je la connait ce qui m'évite ces problèmes.
Mais que ce passerait il si ma base faisait 10000 table comme c'est le cas de grosses bases de données.

Code :

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

1
2
3
L'utilisateur ne servira pas deux fois d'un outil cracra tout pas beau.
Livres-tu des bases accéssibles uniquement en ligne de commande sur écran 14 pouces texte vert sous fond noir ? 
Vois par toi-même, on peut dire que les codes couleurs appliqués ici pour les lignes de code n'a que peu d'intérêt, pour ma part je suis convaincu que cela participe au succès du site.

et oui cela devrait etre capable de fonctionner comme cela et c'est le cas de ces grosses bases.
La programmation est surtout là pour créer l'IHM et faciliter l'utilisation de la base de donnée.
Bonne journée

[Pierre Fauconnier]

.../...
Livres-tu des bases accéssibles uniquement en ligne de commande sur écran 14 pouces texte vert sous fond noir ?
.../...

Il est exact que souvent, on livre la base avec l'interface qui va avec...

Mais de plus en plus, les bases sont "attaquées" par différents canaux, et plus seulement par l'interface conçu initialement. Si je livre une base de gestion de contacts dans une entreprise, il y a fort à parier que cette base sera utilisée par d'autres applications que la mienne (c'est le principe du datawarehouse). Dans ces cas-là, seule l'intégrité référentielle entrera en jeu, et le code mis en remplacement de celle-ci dans l'application initiale sera bien entendu inopérant...

Donc, même si on peut imaginer qu'un code remplace efficacement l'intégrité référentielle (ce dont je doute, où plutôt ce que je crois totalement irréalisable de façon pérenne), il faudra alors garantir l'intégrité en interdisant l'accès par des applis tiers, ce qui diminue considérablement la valeur des données de la base. Pour que les données soient partageables (et donc éviter la redondance des données dans de multiples bases de données et feuilles de calcul),il faudra l'intégrité référentielle pour les accès par d'autres portes d'entrée que le code initial.

J'attends toujours de voir le code pondu pour assurer l'intégrité d'une petite base (mettons une vingtaine de tables, mais les bases avec lesquelles je travaille contiennent souvent plus de cent tables) et ce qui sera mis en place pour garantir l'intégrité lors de l'ajout d'une vingt-et-unième table...

[Arkham46]

Bien sûr que si... Tu peux sans problème laisser la clé externe vide.

Ben j'ai retesté et effectivement on peut laisser la clé externe vide.
J'avais un souvenir que ce n'étais pas possible, peut-être que je confond avec autre logiciel
=> J'ai tout supprimé là où je disais des bêtises.

Conclusion : l'intégrité c'est bien.

[ilank]

Heureux-oli, j'ai aussi vu les catastrophes causées par une intégrité référentielle mal pensée.
Comme par exemple, pour garantir la cohérence entre une table Produits et les tables dépendantes, un effacement en cascade. La suppression d'un produit, l'effacait de toutes les lignes de commandes, factures, bon de livraison, stock.
L'intégrité permet bien de garantir la cohérence des données existantes, qu'aucune donnée dépendante n'est orpheline; mais elle ne garantit ni la véracité des données ni leur sens et encore moins les actions autorisées.

[Pierre Fauconnier]

...
Comme par exemple, pour garantir la cohérence entre une table Produits et les tables dépendantes, un effacement en cascade. La suppression d'un produit, l'effacait de toutes les lignes de commandes, factures, bon de livraison, stock. ...

Pour moi, cet argument ne tient pas... Si je supprime le fichier, je perds aussi mes données.

Il est rare de cocher la case de suppression en cascade lors du placement de l'intégrité. On ne le fait qu'à bon escient en maintenance de tables, et avec des backups.

[Heureux-oli]

Heureux-oli, j'ai aussi vu les catastrophes causées par une intégrité référentielle mal pensée.

Si tu la penses mal dans l'outil Access, comment vas-tu faire pour bien la penser dans ton code ?
Si tu sais penser d'un côté, tu sauras penser de l'autre.

[philben]

Si tu sais penser d'un côté, tu sauras penser de l'autre.

Je ne connaissais pas ce dicton, à méditer

Récemment, on m'a installé l'électricité. Bon jusque là on s'en passait, pensant que c'était du lux ().

Finalement,

• ça nous libère du temps, plus besoin de maintenir le feu et de couper du bois
• Plus confortable pour la douche matinale
• On se sent plus en sécurité avec toutes ces lumières
• Plus facile, un interrupteur et hop !
• Plus portable avec tous ces appareils qui fonctionnent au 220V

Par contre, faut faire attention : J'ai mis une fois les deux doigts dans la prise j'ai dansé jusqu'au matin.

Il existe des progrès qui doivent être partagés par tous !

Philippe

[ilank]

Il est rare de cocher la case de suppression en cascade lors du placement de l'intégrité.

Ah oui et pourquoi donc ? Elle ne fait pas partie de l'intégrité référentielle dont on cause ? Il est pourtant tentant et bien pratique de s'assurer de n'avoir aucun enregistrement orphelin dans une base. A moins que tu ne sois toi aussi pleinement conscient des catastrophes dues à une intégrité mal pensée ?!

On ne le fait qu'à bon escient en maintenance de tables, et avec des backups.

Oui, tu le confirmes. Tu agis en conséquence de la mise en oeuvre de l'intégrité et non pas en disant

Une fois mise en place je n'ai plus à m'en soucier

L'intégrité des données, leur cohérence est un souci permanent non temporaire.

Si tu la penses mal dans l'outil Access, comment vas-tu faire pour bien la penser dans ton code ?
Si tu sais penser d'un côté, tu sauras penser de l'autre.

Mais c'est bien en la pensant dans les deux qu'il m'est arrivé de rencontrer des conflits.
Maintenant, à priori on ne peut savoir qu'on a mal pensé que lorsqu'un problème se déclare; pas au moment-même où l'on pense.

[Pierre Fauconnier]

J'étais bien entendu "un peu trop général" en disant cela. Ce que je voulais souligner, c'est que lorsque la case est cochée, c'est parce que tu sais que tu vas supprimer les enregistrements dépendants, mais on ne place pas la suppression par défaut a priori lors du placement de l'intégrité référentielle.

Et donc, on le fait à bon escient, en ayant pris les précautions nécessaires.

Il y a bien entendu des cas où la placera éventuellement la suppression en cascade (factures et lignes de factures, ...) mais on ne la placera jamais sur une intégrité entre contacts et localités, par exemple.

L'intégrité des données, leur cohérence est un souci permanent non temporaire.

Justement, placer l'intégrité permet de ne pas devoir s'en soucier en permanence. Tu la places à la construction des tables, et tu ne t'en soucies qu'en cas de maintenance... Tu devras par contre t'en soucier en permanence si tu la gères par code...

J'ai vraiment beaucoup de difficultés à suivre tes arguments...

[ilank]

Ce que je voulais souligner, c'est que lorsque la case est cochée, c'est parce que tu sais que tu vas supprimer les enregistrements dépendants, mais on ne place pas la suppression par défaut a priori lors du placement de l'intégrité référentielle.

Qui te parle de le faire "par défaut" ? J'ai uniquement parlé de cohérence des données existantes et d'enregistrements orphelins. Si je coche cette case, vu son effet descendant je vais devoir surtout m'assurer et ce dans le code quel utilisateur a le droit de lancer une telle procédue et des contraintes permettant de le faire.

Justement, placer l'intégrité permet de ne pas devoir s'en soucier en permanence. Tu la places à la construction des tables, et tu ne t'en soucies qu'en cas de maintenance... Tu devras par contre t'en soucier en permanence si tu la gères par code...

Ce n'est pas ce que je pense. C'est bien par soucis de devoir garantir de façon permanent la cohérence des données que je la mets place et dans la base et dans le code.

Il y a bien entendu des cas où la placera éventuellement la suppression en cascade (factures et lignes de factures, ...)

Mais c'est justement parce qu'elle est mise que je dois programmer avec. Quelle facture peut être supprimée, sachant que sa suppression s'applique aussi sur les lignes de facturation ? Supprimes-tu les factures d'un client en contentieux, qui vient de régler un acompte, à qui un encours d'être attribué ?
L'exemple des factures est bien vu. Dans la vie, une facture est un ensemble de lignes de facture, et on ne crée pas de facture vide. Dans un fichier c'est le contraire. Avec une intégrité référentielle, laquelle de ces deux définitions garantit le mieux la cohérence des données du client ?

[Pierre Fauconnier]

.../...
C'est bien par soucis de devoir garantir de façon permanent la cohérence des données que je la mets place et dans la base et dans le code.
.../...

Ce que tu sembles ne pas vouloir comprendre, c'est que tu ne peux "assurer" l'intégrité par code (j'attends toujours le code et sa maintenance ) que si ta base n'est modifiable que via ton application ou ton code, ce qui, je le répète, n'est pas le cas dans 99% des cas professionnels! Alors que l'intégrité référentielle (la "vraie") garantit cela quel que soit l'accès à ta base

.../...
Supprimes-tu les factures d'un client en contentieux, qui vient de régler un acompte, à qui un encours d'être attribué ?
.../...

Les règles comptables ne permettent pas de supprimer une facture, donc le problème ne se pose pas sur ce cas précis. Mais d'une façon générale, c'est pour cela que la case de suppression en cascade ne sera "jamais" cochée par défaut. Ce que ton code devra faire dans ce cas, ce n'est pas supprimer la facture, mais la marquer d'une façon ou d'une autre pour la désactiver. C'est pour cela que je dis que, sauf cas de maintenance où on suppose que l'intervenant sur la base sait ce qu'il fait, les suppressions en cascade ne seront pas autorisées.

Qui te parle de le faire "par défaut" ? J'ai uniquement parlé de cohérence des données existantes et d'enregistrements orphelins. Si je coche cette case, vu son effet descendant je vais devoir surtout m'assurer et ce dans le code quel utilisateur a le droit de lancer une telle procédue et des contraintes permettant de le faire.
.../...

voir ma remarque plus haut.

Mais c'est justement parce qu'elle est mise que je dois programmer avec.
.../...

C'est bien pour cela qu'il ne faut pas la mettre par défaut. Ainsi, tu ne dois pas programmer avec! Ou plutôt, c'est pour cela qu'elle ne sera mise qu'à bon escient (table "brouillard" de saisie temporaire d'une facture avant validation et transfert dans la table des factures et celle des lignes de factures, via une transaction qui garantira la bonne exécution de toutes les manipulations (transfert du brouillard vers les tables définitives et suppression dans les tables temporaires au sein d'une même transaction)

.../...
L'exemple des factures est bien vu. Dans la vie, une facture est un ensemble de lignes de facture, et on ne crée pas de facture vide. Dans un fichier c'est le contraire. Avec une intégrité référentielle, laquelle de ces deux définitions garantit le mieux la cohérence des données du client ?

Il peut parfaitement arriver de créer une facture sans lignes de factures, simplement parce que les lignes seront ajoutées par la suite. Exemple: Je dois établir une facture à fin avril, mais je n'ai pas la donnée me permettant de facturer, mais je dois aussi créer une première facture pour mai. Je vais donc créer une facture vide pour avril, de manière à réserver le numéro séquentiel de la facture, puis je créerai la facture de mai. Plus tard, je recevrai les infos pour la facture d'avril et je la complèterai. Ce cas est très fréquent dans la vie d'une entreprise, je peux te l'assurer.

Au delà de ce cas "extrême", je n'ai jamais prétendu que l'intégrité palliait à tout, et ton code pourra très bien interdire la pratique décrite plus haut, mais à nouveau, cette protection ne sera de toute façon opérationnelle qu'à l'intérieur de ton application, et pas pour des manipulations externes à celles-ci.

Jusqu'ici, je n'ai encore rencontré aucun argument en faveur d'une gestion de l'intégrité par code plutôt que via les outils liés au SGBD. Je n'ai pas dit, cependant, que l'intégrité parait à tous les coups, mais il me paraît évident qu'il vaut mieux l'intégrité que pas l'intégrité, cela ne dispensant pas d'un code qui, dans une application précise, permettra ou interdira une action sur des données de la base, en complément de l'intégrité qui, elle, palliera aux déficiences "éventuelles" du code, et garantira, je le répète à nouveau, l'intégrité des données en cas de manipulations externes au code créé. J'attends que tu nous expliques comment ton code palliera aux "attaques" externes de la base.

Je me demande si tu envisages vraiment bien la "vraie" vie d'une base de données et les multiples manipulations qu'elle subit, via le code de son application "mère" ou via, et c'est là que l'intégrité montre toute sa puissance par rapport à l'inutilité de ton code, des attaques externes.

[ilank]

Bonjour à tous,

j'avais zappé ceci

Code :

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

1
2
3
4
5
6
7
Private Sub Form_Error(DataErr As Integer, Response As Integer)
    If DataErr = 3200 Then
        MsgBox "Vous ne pouvez pas supprimer cet enregistrement. Il est utilisé par d'autres données de l'application", _
            vbInformation, "Suppression d'un enregistrement"
        Response = acDataErrContinue
    End If
End Sub

Voilà ce que j'appelle programmer avec l'intégrité référentielle. Pour garantir la cohérence des données, tu gères l'accessiblité des actions sur les données.

Ce que tu sembles ne pas vouloir comprendre, c'est que tu ne peux "assurer" l'intégrité par code (j'attends toujours le code et sa maintenance ) que si ta base n'est modifiable que via ton application ou ton code, ce qui, je le répète, n'est pas le cas dans 99% des cas professionnels! Alors que l'intégrité référentielle (la "vraie") garantit cela quel que soit l'accès à ta base

en fait, la véritable question selon moi est :
Utiliserez-vous les relations et l'intégrité référentielle si :
1) Si vous savez que la base de données que vous concevez sera exploitée par une application développeée par un tiers ?
2) Si en plus de la conception de la base, vous êtes le développeur de l'application, seul outil permettant d'exploiter et gérer les données ?

Ce que toi, tu ne sembles pas comprendre Pierre, c'est que l'intégrité référentielle ne porte que sur les données contenues dans la base, et pas sur ce qui lui est envoyé, ni sur les manipulations des données. Or, les manipulations des données ne sont que de 2 ordres :
- consultation : Impression écran, impression papier
- écriture : création, édition/modification, suppression

C'est bien par souci de garantir la consultation, que tu gères les actions d'écriture sur la base. Par exemple, pour garantir l'interdépendance entre plusieurs tables, tu emploies des tables temporaires, et tu associes le formulaire de saisie à la tabe temporaire et non directement aux fichiers d'enregistrement. Et je suis sûr que tu ne placeras pas dans le schéma de la base, les tables temporaires, elles font partie de l'appli donc du code.
Voilà un exemple de ce que j'appelle programmer avec l'intégité référentielle.

[Pierre Fauconnier]

Salut!

.../...
Voilà ce que j'appelle programmer avec l'intégrité référentielle.

Je n'ai pas relu tous tes messages, mais il ne me semble pas que tu parlais de programmer avec l'intégrité, mais que tu parlais de programmer l'intégrité. La nuance est de taille, puisque si tu programmes avec, cela veut dire que tu la places... (courbe rentrante de notre ami ilank? )

Pour garantir la cohérence des données, tu gères l'accessiblité des actions sur les données.

Pas du tout. Je ne fais que gérer l'erreur, c'est-à-dire modifier le message d'erreur abscons d'Access lié à l'impossibilité de suppression suite à l'intégrité en un message (que j'espère) plus compréhensible, mais je ne gère pas du tout l'accessibilité par code.

Ce que toi, tu ne sembles pas comprendre Pierre, c'est que l'intégrité référentielle ne porte que sur les données contenues dans la base

Relis-moi, et tu verras que je dis cela dans plusieurs de mes messages. L'intégrité ne porte que sur les données de la base, mais garantit l'intégrité, quelle que soit l'application ou la technique qui manipule lesdites données, alors que ton code ne gère (avec) l'intégrité que dans ton application, en étant inexploitable par une autre application.

Ce que toi, tu ne sembles pas comprendre Pierre, c'est que l'intégrité référentielle ne porte que sur les données contenues dans la base
et pas sur ce qui lui est envoyé, ni sur les manipulations des données.

Je ne comprends pas ce que tu dis. Justement, l'intégrité référentielle porte sur ce qui est envoyé à la base et sur les manipulations de données. (voir plus haut)

J'ai de plus en plus de difficultés à te suivre (Y en a d'autres qui suivent?)