Discussion :

[Pierre Fauconnier]

Salut,

...

Ben... Des sauvegardes

Pas compris non plus... (l'impression d'être bouché à l'émeri, ce matin...)

[Chtulus]

Salut Pierre et Arkham l'extraterrestre ,

Pas compris non plus...

Dans le cadre d'une sauvegarde des données uniquement, il n'y a pas besoin de prendre en compte les intégritées...

Ce qui rejoint l'idée je pense de vodiem () au moins pour la première partie.

ex: la base d'origine contrôle l'intégrité, l'envoie à une autre (sans relations)

La doc papier suffit à remonter la base

Par contre je suis plus sceptique

Genre une commande mais tu ne veux pas renseigner le magasin de réception parce que tu ne le connais pas encore.

Quelqu'un te passe commande mais tu ne sais pas qui ?

Bon je tends le baton pour me faire battre...

[ilank]

Bonjour à tous,
vaste sujet.
a mon humble avis on peut distinguer deux approches :
celle des développeurs d'applications, celle des administrateurs de bases de données.
Le développeur voit la base de données au niveau de l'application qu'il a à développer.

Le développeur place les relations et l'intégrité d'abord et avant tout au niveau de l'application, par exemple : un bouton de suppression d'enregistrements n'est disponible que lorsque les conditions permettant l'éxécution de l'action sont remplies si elles le sont pas, le bouton est grisé; voir même pas visible. Et je suis quasi sûr que ceux et celles qui utilisent relations et intégrité référentielle ne s'en préoccupent pas. Pour le développeur, l'application gère bien plus des entités (ou objets) que des enregistrements dans des tables.

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 ?

[Pierre Fauconnier]

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 ?

Pas compris ce qui est en gras

Le développeur place les relations et l'intégrité d'abord et avant tout au niveau de l'application, par exemple : un bouton de suppression d'enregistrements n'est disponible que lorsque les conditions permettant l'éxécution de l'action sont remplies si elles le sont pas, le bouton est grisé; voir même pas visible. Et je suis quasi sûr que ceux et celles qui utilisent relations et intégrité référentielle ne s'en préoccupent pas.

Dans une base de données un peu conséquente, en Access en tout cas, c'est la mort du réseau de faire ce que tu proposes, en plus du temps de développement et de maintenance (maintenance qui sera quasi impossible, selon moi). Si, lorsque je visualise la fiche d'un client, je dois, pour afficher le bouton de suppression, vérifier s'il a passé une commande, une demande d'offre, payé ses factures et tout le reste, je vais écrire du code à gogo et saturer mon réseau de requêtes très lourdes (ne pas oublier qu'Access n'est pas un serveur de données, donc bonjour le trafic réseau) juste pour ne pas mettre de l'intégrité référentielle...

Et je suis quasi sûr que ceux et celles qui utilisent relations et intégrité référentielle ne s'en préoccupent pas.

Bien entendu que je ne me préoccupe pas de griser un bouton lorsque je place l'intégrité référentielle, puisque celle-ci prendra le cas en charge bien plus sûrement que moi. Mais c'est juste ma religion, je ne l'impose à personne, mais je serais curieux de voir tourner une appli sérieuse et conséquente (pas juste deux tables pour rire) sur un réseau avec ce genre de dispositif "ergonomique"...

Question: Es-tu vraiment sérieux lorsque tu écris cela? (c'est en forme de boutade, bien sûr )

[ilank]

Bonjour Pierre,

Tu ne fais que confirmer mes propos.
L'utilité des relations et autre intégrité référentielle n'est pas empirique mais dépend de l'approche que chacun a de la conception d'un outil Access.
Certains ont une approche de développeur d'application et pour eux c'est au niveau applicatif que les premières contraintes s'appliqueront, comme par exemple ne pas présenter à l'utilisateur des actions qu'il ne peut pas exécuter ce qui garantit que l'action ne sera effectivement pas exécutée; d'autres ont une approche d'administrateur BD et pour eux c'est avant tout la base qui se doit d'être sioux quelque soit l'application.
Il n'y a aucune critique de ma part concernant ces deux approches; elles me paraîssent juste différentes et primordiales pour comprendre les réponses de chacun.

Dans une base de données un peu conséquente, en Access en tout cas, c'est la mort du réseau de faire ce que tu proposes, en plus du temps de développement et de maintenance (maintenance qui sera quasi impossible, selon moi). Si, lorsque je visualise la fiche d'un client, je dois, pour afficher le bouton de suppression, vérifier s'il a passé une commande, une demande d'offre, payé ses factures et tout le reste, je vais écrire du code à gogo et saturer mon réseau de requêtes très lourdes (ne pas oublier qu'Access n'est pas un serveur de données, donc bonjour le trafic réseau) juste pour ne pas mettre de l'intégrité référentielle...

C'est bien dans un tel contexte, que le développeur et le bda se diffèrent c'est pourquoi j'ai écrit :un développeur gère bien plus des objets que des enregistrements dans des tables et j'ajoute là où ta réaction prend pour point de départ la base de données, le développeur s'interrogera d'abord au niveau applicatif.

Pour finir, je crois qu'un développeur se sert d'une base pour stocker les données que son application génère là où un bda se sert d'une application pour visualiser les données que sa base gère. Dans les deux cas, il y a gestion des relations et de l'intégrité référentielle, elles ne sont en fait pas situées au même niveau.

[Pierre Fauconnier]

Pour conclure, en ce qui me concerne, suite à ce que j'ai exposé dans cette discussion sur les multiples raisons qui me poussent à préférer l'intégrité sur les tables que par code, je dirais, puisque l'on est sur un forum de développeurs professionnels (ne l'oublions pas), et tu comprendras ainsi que je ne suis pas du tout d'accord avec tes propos, que:

Si je devais engager quelqu'un pour m'aider dans mes développements et qu'il me tenait les propos que tu tiens, soit je ne l'engage pas , soit je le vire si je l'ai déjà engagé..., car je ne pourrais avoir aucune confiance dans son travail, et qu'il ne m'apparait pas comme étant du domaine des "préférences" d'utiliser ou non l'intégrité référentielle ou de lui préférer du code, selon que l'on est plus du côté BD que du côté Développeur. Je dirais que, pour ma part, ce n'est pas un choix de mettre ou non l'intégrité référentielle, c'est une obligation pour un développeur qui veut faire un travail sérieux, maintenable et pérenne.

[EDIT]
Et je dirais que si un développeur - professionnel - doit intervenir sur une base qu'il ne gère pas, il doit:
- soit s'assurer auprès du gestionnaire que l'intégrité est prévue et mise en place
- soit se protéger, dans la convention qui le liera à son client, de tout dysfonctionnement qui découlerait du manque avéré au niveau du gestionnaire de la base
- dans les deux cas, faire attention dans son devis qu'il devra, si l'intégrité des bases n'est pas "activée", revoir à la hausse les temps de développement et de tests qu'il devra réaliser, en précisant bien à qui la responsabilité de ces coûts supplémentaires incombe... (et il ne s'agit pas ici d'assurer uniquement que des boutons soient actifs ou non, mais bien que l'on ne risque pas de détruire des données via (et à cause de ) l'application.
[/EDIT]

Tes propos, cela revient un peu à dire: J'utilise SQL Server, mais je ne me sers ni des triggers ni des fonctions ou procédures stockées, car je préfère coder parce que je suis développeur et pas gestionnaire de BD , et que de toute façon, ces trucs-là, c'est gavant . C'est vraiment pour moi un non-sens. Désolé de paraître si dur ou intransigeant, mais je ne peux ratifier ce genre de choix.

Mais à nouveau, ce n'est que ma religion, et mon "blocage" n'est évidemment pas envers toi personnellement, j'espère que tu l'auras compris. Néanmoins, je ne changerai pas de secte

[Invité]

Salut

Mais à nouveau, ce n'est que ma religion, et mon "blocage" n'est évidemment pas envers toi personnellement, j'espère que tu l'auras compris. Néanmoins, je ne changerai pas de secte

Pierre, nous faisons parti de la même secte .

[Chtulus]

Re,

Pour rajouter une pierre à l'édifice de Pierre...

Dire

le développeur s'interrogera d'abord au niveau applicatif

Sans parler de développeur, hein, mais penser à l'applicatif de la façon dont tu le vois (développement) avant de penser à la structure (modèles) de la base c'est foncer tout droit dans le mur...

Les bases de données ne sont pas des joués (Enfin on peux jouer avec ) c'est un peu comme construire une cathédrale en ce disant tiens les cloches vont sonner, je doute de la solidité des fondations...

(Punaise, je crois que je n'est pas finit la digestion...)

[Edit]
bda = bande déssinée animée = mangas
dba = Data Base Administrator = Administrateur de base de données
[/Edit]

[ilank]

Je ne prends pas tes remarques personnellement, puisque en fait, je n'ai pas indiqué ce que je faisais moi-même. Mon propos n'est pas d'établir ce que je préfère mais l'approche que chacun de nous peut avoir sur le sujet. Je signale juste que l'on a tous des habitudes selon que l'on soit bda de formation ou développeur.

Si je devais engager quelqu'un pour m'aider dans mes développements et qu'il me tenait les propos que tu tiens, soit je ne l'engage pas , soit je le vire si je l'ai déjà engagé...

Tu as bien raison, d'autant que je ne voudrais pas plus dans mon équipe d'un développeur qui affirme :Bien entendu que je ne me préoccupe pas de griser un bouton lorsque je place l'intégrité référentielle,....

[curt]

Bonjour à tous,

je suis adepte de la même secte que Pierre et Philippe....

Ah les relations !!!! on est bien seul quand on en a pas

On reste en contact (et en relation)

Curt

[marot_r]

Moi aussi je ne peut concevoir d'argument en faveur de l'abscence d'intégrité référentielle.

Je l'ai connu à mes début quand je montais des fichiers séquentiels indéxés en COBOL et où l'intégrité référentielle était faite à la main, par code. L'équivalent de par requète et je peux assurer que malgrés tout le soin mis dans ce processus il y avait toujours un moment où quelqu'un oubliait de mettre le code nécessaire et où on se retrouvait avec des orphelins et des parents dépossédés.

Et j'ai vécu une situation semblable il y a environ 1 ans où j'ai hérité de 3 bases Access montées sans intégrité ... un vrai cauchemard technique mais les clients en était content ... jusqu'à ce que je fasse un peu d'exploration et d'analyse de données et qu'ils s'apperçoivent que cela faisait presqu'un an que leur chiffres étaient faux sans qu'ils le sachent.

Mon argument massue POUR l'intégrité c'est qu'une fois qu'elle a été définie dans la fenêtre de relation, c'est à dire à une seul place, tu peux l'oublier et tu es certain qu'elle sera maintenue. C'est le moteur de la base, plus toi qui s'en occupe.

A+

[Pierre Fauconnier]

Ilank,

Tu as bien raison, d'autant que je ne voudrais pas plus dans mon équipe d'un développeur qui affirme :Bien entendu que je ne me préoccupe pas de griser un bouton lorsque je place l'intégrité référentielle,....

Je serais curieux que tu me détailles comment tu fais par code, pour désactiver le bouton Supprimer lorsque l'utilisateur affiche la fiche signalétique d'un contact qui a passé des coups de fils, des commandes, reçu des factures, effectué des paiements, reçus des rappels, et qui est à la fois fournisseur et donc pour lequel il y a des livraisons, des factures fournisseurs, des réclamations, ... (type CRM/ERP). Il me semble, mais je peux me tromper, que avec Access en tout cas, tu mets ton réseau à genoux avec toutes les requêtes que tu vas devoir lancer.

Mais je t'assure que, au delà de toute polémique, je serais vraiment curieux de voir le code qui devrait être développé.

Cela étant, je trouve ce débat intéressant...

[ilank]

Je serais curieux que tu me détailles comment tu fais par code, pour désactiver le bouton Supprimer lorsque l'utilisateur affiche la fiche signalétique d'un contact qui a passé des coups de fils, des commandes, reçu des factures, effectué des paiements, reçus des rappels, et qui est à la fois fournisseur et donc pour lequel il y a des livraisons, des factures fournisseurs, des réclamations, ... (type CRM/ERP). Il me semble, mais je peux me tromper, que avec Access en tout cas, tu mets ton réseau à genoux avec toutes les requêtes que tu vas devoir lancer.

Mon véritable soucis est plutôt de valider le bouton, par défaut on ne peut supprimer que ce qui existe.
2, il y a la définition même de l'entité au niveau applicatif. Est-ce qu'un fournisseur est tout enregistrement de la table fournisseurs ou toute entité ayant au moins une commande en tant que fournisseur ?
3, il y a le scénario d'accès jusqu'à la fiche; Est-ce que l'utilisateur accède à tous les contacts quelque soit leur qualité ou puisque le contact identifie un fournisseur il faut d'abord passer par la collection fournisseurs, le fournisseur, la collection de ses contacts et enfin la fiche;ou par les appels reçus...
4, il y a la définition des droits de l'utilisateur courant sur la fiche.
Comme tu peux le voir, l'intégrité n'est pas niée elle fait partie de la logique de programmation, en revanche je sais qu'il arrive qu'elle rentre en conflit avec l'algo prévu et que là il faut faire un choix; modifier l'algo ou ne pas mettre en place l'intégrité au moins pour les tables considérées.

Maintenant, d'après ton exemple, je peux très bien mettre en place une suppression en cascade et puisque le bouton n'est jamais grisé l'action est toujours disponible quelque soit le contact, ses commandes, factures... que je supprimerai le tout, tout en respectant rigoureusement l'intégrité mise en place. Est-elle pour autant correcte ?

Mais je t'assure que, au delà de toute polémique, je serais vraiment curieux de voir le code qui devrait être développé.

Ben, déjà je ne pensais en faire; j'ai juste voulu signalé qu'un programmeur s'oriente plus volontiers sur ce que fait et doit faire son code qu'un admnistrateur de base de données. A aucun moment, je n'ai prétendu qu'il fallait procéder det telle ou telle manière; qu'il était inutile de faire telle ou telle chose; mais juste qu'il existe deux approches différentes de la conception d'une appli Access. J'ai vraiment du mal à comprendre vos réactions

[vodiem]

moi je suis pas sectaire: chaque religion a du bon, il faut prendre le meilleur de chacune.

je pense qu'il n'est pas sage de porter un jugement globale sur la qualité d'un programmeur uniquement sur ces critères.
j'ai une préférence à croire que l'outil et au service de l'homme et pas le contraire alors j'aurais tendance à privilégier l'approche 'développeur d'application' plus que 'administrateur BD' pour reprendre l'idée d' ilank bien qu'il ne précise pas qu'il s'agit d'approches antagonistes.

je voudrais préciser que l'héritage d'une base sans avoir cette fenêtre complétée ne conduit pas inéluctablement à des problèmes et que toutefois comme tout le monde le dit: l'inverse peut en éviter.

C'est le moteur de la base, plus toi qui s'en occupe.

c'est sur à résultat égale j'aurais tendance à ne pas coder et faire mes relations...

[ilank]

Bonsoir Vodiem, je ne suis pas sûr que les deux approches soient antagonistes; personnellement je pense qu'elles sont juste aux deux extrémités d'une même chaine.
J'ai eu un temps l'objectif d'unifier les deux approches, le problème majeur est qu'il me paraît impossible d'après mes compétences de démarrer par les deux; il faut faire le choix d'une approche.

[vodiem]

bonsoir ilank, je voulais dire par là que l'un n'empêche pas l'autre et qu'il est toujours bon d'avoir plusieurs point de vue.

[=JBO=]

Bonjour, Bonsoir !

Dans mon travail, à plusieurs reprises il n'était pas possible de mettre en place l'intégrité référentielle "automatique".

• Par exemple, lorsqu'on travaille avec des tables attachées ODBC.
• Autre exemple: des tables réparties dans différents fichiers MDB (plusieurs dorsales).

Donc, il faut pouvoir travailler sans confier l'intégrité référentielle au moteur de bases de données.

Au passage, ceci n'empêche pas de dessiner "la relation" dans la fenêtre des relations d'un fichier MDB frontal, mais on ne peut pas l'utiliser pour l'intégrité référentielle.
_

[Domi2]

Bonsoir à tous,

Excellent débat...

Je ne cite personne en particulier (de peur d'en oublier... et de fameux )...

Je compte quand même (j'espère ne pas trop me tromper) :

Des "pros relations et intégrité référentielle"...

A tout le moins un "provocateur", qui fait avancer le débat...

Et au moins un "iconoclaste", qui n'hésiterait pas à s'écarter des sentiers battus...

Je suis très mal placé pour juger de la pertinence de tous les arguments et propos, surtout techniques.

Je relève tout de même dans la discussion un point qui me "trouble". On en vient à argumenter une approche différente du problème, qu'on soit "développeur" ou "administrateur de bases de données"... Ce qui est peut-être primordial du point de vue "de l'informaticien"...

Mais en définitive, c'est un utilisateur "lambda" qui va dans la majorité des cas utiliser une application... Et on en parle peu (ou pas) dans cette discussion...

L'un ou l'autre choix lui procure-t-il des avantages (je parle de l'utilisateur)...

- convivialité ?
- facilité d'utilisation ?
- sécurité lors de l'utilisation ?

Perso, je travaille sur un application "métier" qui n'offre pas de "relations et d'intégrité réferentielle", en tout cas pas sans "coder" à tout va... (ce qui n'est pas fait, mal fait, en cours de développement...).

Et bien, je la change demain... (si mon budget le permet... ).

Mon choix et donc assez rapidement fait... "Relations et intégrité référentielle"...

Domi2

[ilank]

Bonjour,

Perso, je travaille sur un application "métier" qui n'offre pas de "relations et d'intégrité réferentielle", en tout cas pas sans "coder" à tout va... (ce qui n'est pas fait, mal fait, en cours de développement...).

Ok, je comprends mieux maintenant les réactions que mes posts ont suscité.
Je n'ai pas voulu dire, que le développeur ne se soucie pas des relations et intégrité référentielle mais, au contraire qu'il programme avec. Et c'est justement, parce qu'il s'en soucie, qu'il est amené à les intégrer dans son algo, et peut ne pas les mettre en place pour cause de conflit avec l'algo, ou autres contraintes.
Bref, j'ai juste pensé que les seules personnes qui ici, diront qu'elles ont du parfois se passer de l'intégrité référentielle sont des développeurs. J'ai du mal m'exprimer.

[Pierre Fauconnier]

J'aime bien ce débat...

Bref, j'ai juste pensé que les seules personnes qui ici, diront qu'elles ont du parfois se passer de l'intégrité référentielle sont des développeurs

A mon avis, tu risques d'en fait bondir plus d'un avec ces propos (), même si ceux-ci nous éloignent du sujet, et même si "développeur" est une notion qui englobe tout et son contraire...

Domi2,

Avant de me positionner du point de vue de l'utilisateur, je voudrais juste aborder une notion que l'on a abordé assez peu dans ce débat, c'est la notion du coût de développement. J'ai juste effleuré le sujet dans un de mes messages. Ce point n'est pas à négliger, car, in fine, c'est le client qui paie. Personnellement, en plus des aspects pratiques, je trouve plus rentable de gérer les évènements d'erreur de formulaire, qui sont somme toute assez génériques, via quelques lignes de code comme celles-ci, qui gèrent le refus de suppression suite à l'intégrité référentielle

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

plutôt que de vomir du code pour "gérer" l'intégrité que je devrai adapter à chaque modification dans la structure de mes données (ajout d'une table => revomir du code pour assurer l'intégrité). J'ai vraiment beaucoup de difficultés à imaginer que l'on puisse préférer du code difficilement maintenable à l'intégrité référentielle...

Je suis aussi un peu "troublé" par le fait que l'on "oppose" un regard développeur à un regard gestionnaire de BD. Pour moi, le développeur qui doit gérer des données utilise les outils mis à sa disposition par la technologie utilisée, outils dont fait partie l'intégrité référentielle. C'est ce qui me fait dire qu'une personne qui développe une interface sur Access lié à du SQL Server devra se servir des triggers, des fonctions et procédures stockées, et ne pourra pas, à mon avis, se contenter de migrer sa base Access, simplement parce qu'il est "développeur" et pas "gestionnaire de données", et qu'il préfère, par exemple, mettre par code la date de modification de l'enregistrement alors qu'un trigger fera cela aussi bien, avec plus de sécurité et en utilisant les ressources serveur...

Pour ce qui est du regard "utilisateur", je dirai que la convivialité, la facilité et, dans une moindre mesure, la sécurité sont des notions très subjectives.
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. Quant à la sécurité lors de l'utilisation, je pars du principe qu'elle n'est pas à charge de l'utilisateur (de l'application ou de techniques d'attaque de la base par ODBC ou autre). Elle doit être mise en place par le développeur, qui sera grandement aidé par l'utilisation de l'intégrité référentielle...

Je rejoins JBO lorsqu'il parle de l'impossibilité de placer de l'intégrité "interbases", mais c'est me semble-t-il un autre débat, et de toutes façons, à mon avis, on sera grandement aidé par l'utilisation de l'intégrité à l'intérieur de chaque base de "l'usine à gaz"...

Allez, bon 1er mai avec le muguet et tout et tout...