Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 16 sur 16
  1. #1
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 113
    Points
    113

    Par défaut Une base de données sans liens ni triggers

    Utilisez-vous des liens entre les tables, dans vos développements ? Des liens déclarés au niveau de la base, comme par exemple l’intégrité référentielle ?

    J’ai vu une application avec des dizaines de tables, sans aucun lien entre les tables. Tout est géré par le programme, y compris l’intégrité référentielle. A priori donc, sauf bug, il ne peut y avoir d’incohérence dans sa base.

    Je n’ai aucun problème avec les notions présidant à la conception de base de données, mais je n’ai pas l’expérience d’un gros développement avec. Aussi je me demande si c’est la meilleure façon de coder une application qui se sert intensément d’une base de données.

    J’essaie de voir le pour et le contre.

    - Je suppose que la conception de la base (scripts de création des tables et scripts de mise à jour des tables) est plus simple comme cela, puisque que l’on ne se préoccupe pas de lien ou d’intégrité.
    - Je me pose des questions sur les performances. Admettons que le programme ne soit pas bugué, n’obtient-on pas les résultats plus rapidement, en général, si l’on affiche des données d’une table parent et de sa table enfant, s’il y a déjà un lien au niveau de la base ?
    - Est-ce que la gestion des erreurs n’est pas plus sure, si une violation d’intégrité référentielle est signalée par une exception générée par un trigger, au niveau de la base, plutôt que codée dans l’application ?

    Bref, je suis un peu confus, là, car il me semblait naturel, jusqu’ici, de définir au moins les liens d’intégrité référentielle au niveau de la base.

    Votre avis ? Merci de vos réponses

  2. #2
    Membre habitué Avatar de Casp
    Homme Profil pro Yann
    Ingénieur d'études nouvelles technologies
    Inscrit en
    avril 2003
    Messages
    128
    Détails du profil
    Informations personnelles :
    Nom : Homme Yann
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études nouvelles technologies
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : avril 2003
    Messages : 128
    Points : 103
    Points
    103

    Par défaut

    salut,

    en ce qui concerne la définition de ta base de données, il est préférable à mon avis de définir les contraintres d'intégrités au niveau de tes tables car sur un plan de sécurité c'est beaucoup plus sur pour avoir une base de données cohérentes. de plus cela va éviter de faire des vérifications au niveau de ton code qui peux predre du temps si par la suite tu as une grosse base de données.

    voiola ce que j'en pense

    bon courage

  3. #3
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 113
    Points
    113

    Par défaut

    C'est aussi ce que je pense, mais j'aimerais avoir des arguments plus solides à présenter...

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 563
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 563
    Points : 30 071
    Points
    30 071

    Par défaut

    J’ai vu une application avec des dizaines de tables, sans aucun lien entre les tables. Tout est géré par le programme, y compris l’intégrité référentielle. A priori donc, sauf bug, il ne peut y avoir d’incohérence dans sa base.
    C'est du crétinisme pur : sauf à utiliser massivement des transactions, le risque de toute coupure du poste client entraînera fatalement une désintégrité de la base. J'ai audité de nombreuses applications avec ce genre de connerie. Toutes se sont plantées. Tous on réalisé en catastrophe une moulinette pour vérifier l'intégrité. Sans penser que ce qui se fait directement dans un serveur est incommensurablement plus rapide qu'un traitement local avec des aller et retour entre serveur et client !


    Je n’ai aucun problème avec les notions présidant à la conception de base de données, mais je n’ai pas l’expérience d’un gros développement avec. Aussi je me demande si c’est la meilleure façon de coder une application qui se sert intensément d’une base de données.
    C'est tout simplement la pire !

    J’essaie de voir le pour et le contre.

    - Je suppose que la conception de la base (scripts de création des tables et scripts de mise à jour des tables) est plus simple comme cela, puisque que l’on ne se préoccupe pas de lien ou d’intégrité.
    Tout simplement parce que les crétins qui réalisent de telles bases de données n'utilisent pas les outils adéquats et généralement ne savent même pas ce qu'est un modèle de données.
    Avec un outil efficace de modélisation on ne touche JAMAIS directement la base. C'est l'outil qui le fait, même si le script SQL est complexe. Dont aucun problème de gestion des IR. Les gens qui arguementent comme tu le dit sont des ignares.

    - Je me pose des questions sur les performances. Admettons que le programme ne soit pas bugué, n’obtient-on pas les résultats plus rapidement, en général, si l’on affiche des données d’une table parent et de sa table enfant, s’il y a déjà un lien au niveau de la base ?
    Tu as raison de te poser ces questions : les perfs ne peuvent qu'être médiocre parce que l'automatisation de la pose d'index, comme le calcul du plan de requête, et le plan résultant, concourreront à une moindre efficacité.

    - Est-ce que la gestion des erreurs n’est pas plus sure, si une violation d’intégrité référentielle est signalée par une exception générée par un trigger, au niveau de la base, plutôt que codée dans l’application ?
    Elle est encore plus sûre, rapide et performante, s'il s'agit d'une IR interne, c'est à dire gérée par la base et non pas par trigger. De plus certaines options de gestion de l'IR sont très difficile à réaliser alors qu'au niveau de la création de la base il s'agit d'une simple option dans la définition de la contrainte.
    A lire sur le sujet :
    http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.3

    Bref, je suis un peu confus, là, car il me semblait naturel, jusqu’ici, de définir au moins les liens d’intégrité référentielle au niveau de la base.
    Oh que oui, sans aucune exception, si ce n'est celle de l'ignardise crasse. Et en cette matière le manque de formation a SQL, aux principes des SGBDR et à la modélisation des données est hélas de plus en plus catastrophique en France !
    Ton interrogation est révélatrice de la lourdeur des imbécilités qui circulent parfois dans le milieu informatique...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  5. #5
    Membre du Club
    Inscrit en
    avril 2003
    Messages
    79
    Détails du profil
    Informations forums :
    Inscription : avril 2003
    Messages : 79
    Points : 53
    Points
    53

    Par défaut

    Lu,

    Je suis confronté a ce "probleme" actuellement.
    Le chef de projet, n'aime pas mettre des clefs etrangere dans ses modeles de base de données.
    C'est la premiere remarque que j'ai fait quand j'ai voulu attaquer sa base avec ReportNet.
    En effet, les outils de ce genre, se servent de ces informations pour importer le modele.
    Du coup là je dois les faire depuis ReportNet, alors que ça devrait être géré automatiquement, et surtout en accord parfait avec les choix de modelisation du concepteur.

    L'argument qu'il invoque c'est que Oracle gueule lors du chargement des tables.

    Comment doit on s'y prendre pour faire ça dans les regles de l'art ?

  6. #6
    Expert Confirmé Sénior
    Avatar de christopheJ
    Profil pro
    Inscrit en
    avril 2004
    Messages
    1 612
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Indre et Loire (Centre)

    Informations forums :
    Inscription : avril 2004
    Messages : 1 612
    Points : 7 991
    Points
    7 991

    Par défaut

    Je suis confronté à ce probleme aussi...
    Mon application se greffe sur la base de données de l'ERP maison. C'est une base avec environ 400 tables, pas de doc (la transmission du savoir est orale comme pour les légendes dans les peuplades primitives...), pas de clés etrangères ou contraintes d'intégrité, donc pas d'outils de reverse fonctionnant correctement...
    De plus comme ils n'utilisent pas de champs unique pour servir de clé dans certaines tables, on arrive à des abbérations du genre 11 champs dont 9 dans la clé primaire et un pour la date de modif...
    Rien que pour les gens qui seraient amener à developper autour de ta base pour la suite, utilise des clés étrangères et contraintes....
    Rédacteur - modérateur Java
    Les FAQ Java
    Les cours et tutoriels Java

  7. #7
    Expert Confirmé Sénior
    Avatar de qi130
    Homme Profil pro Pierre
    Expert Processus IT
    Inscrit en
    mars 2003
    Messages
    3 731
    Détails du profil
    Informations personnelles :
    Nom : Homme Pierre
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Expert Processus IT
    Secteur : Finance

    Informations forums :
    Inscription : mars 2003
    Messages : 3 731
    Points : 5 677
    Points
    5 677

    Par défaut

    Citation Envoyé par mirak63

    L'argument qu'il invoque c'est que Oracle gueule lors du chargement des tables.

    Comment doit on s'y prendre pour faire ça dans les regles de l'art ?
    Il faut, au choix:

    - soit charger en 1er les tables référencées
    - soit lever temporairement les IR
    "Il n'y a pas de bonnes réponses à une mauvaise question." (M. Godet)
    -----------------------
    Pensez à cloturer votre sujet - Aucune réponse aux sollicitations techniques par MP
    Usus magister est optimus

  8. #8
    Inactif Avatar de Médiat
    Inscrit en
    décembre 2003
    Messages
    1 946
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 1 946
    Points : 2 170
    Points
    2 170

    Par défaut

    Citation Envoyé par qi130
    - soit charger en 1er les tables référencées
    - soit lever temporairement les IR
    Si Oracle "Gueule", c'est qu'il a de bonnes raisons, j'ajouterais donc à ta liste :
    - Charger des données cohérentes ! Et justement ORACLE avec IR déclarée, vérifie que les données sont cohérentes :
    ORACLE 1 "Le chef de projet qui n'aime pas mettre des clés étrangères " 0.

  9. #9
    Expert Confirmé Sénior
    Homme Profil pro
    BI
    Inscrit en
    mars 2003
    Messages
    1 513
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : BI

    Informations forums :
    Inscription : mars 2003
    Messages : 1 513
    Points : 4 255
    Points
    4 255

    Par défaut

    Les contraintes d'intégrité sont absolument effectivement indispensables dans les SGBDR dans le cas contraire on se retrouve avec une base de plus en plus bancale.

    Les causes de ce refus des contraintes d'intégrité peuvent effectivement provenir d'une méconnaissance grave de la modélisation et des bases des SGBDR.

    Mais je vois deux autres causes.

    Certaines personnes proviennent du monde des gros et moyens systèmes et ont aucune idée des contraintes d'intégrité des SGBD Relationnels et en fait appliquent les méthodes des bases de données hiérarchiques. Ce style de base est trés loin des SGBDR mais si les personnes sont compétentes en base de données hiérarchiques ce genre de base tient pas trop mal la route malgré que ce soit une hérésie du point de vue des SGBDR, et que l'intégrité de ces bases sera tout de même très dur à mainternir.

    Une autre cause beaucoup plus grave provient du fait que l'expression des besoins a été baclée ainsi que la modélisation au sens large du terme. Autrement dit plutôt que de faire des efforts pour que la modélisation soit conforme aux demandes des utilisateurs, les tables sont conçues en dépit du bon sens, et des colonnes sont rajoutés au petit bonheur la chance de temps en temps sans vue d'ensemble. En fait ce n'est pas tant le fait que les tables ne soient pas normalisées c'est surtout que tout le travail en amont des besoins fonctionnelles des utilisateurs a été complétement éludé.
    Donc évidemment dans ce cas les contraintes d'intégrité ne font pas long feu car tout les jours un cas non prévu remettra en cause ces contraintes.

    edit:
    Citation Envoyé par christopheJ
    Mon application se greffe sur la base de données de l'ERP maison
    Les ERP (ou autres CRM) sont le plus souvent des cauchemards que cela soit du point de vue de la normalisation que des contraintes d'intégrité...sans parler du typage des données. Tout cela pour s'économiser du temps de développement, et de maintenance évolutive, spécifique à chaque plateforme et accessoirement pour rendre leur modèle incompréhensible.

  10. #10
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 113
    Points
    113

    Par défaut

    Bien, merci de toutes ces réponses qui me rassurent quant à ce que je pensais : il vaut mieux définir ces contraintes au niveau de la base. Et ce d’autant plus que j’ai appris depuis que des techniciens de maintenance font parfois des interventions directes sur les tables, manuellement, et donc sans aucune garantie de cohérence dans les données…


    Bon... Une appli sans documents de spécification, sans doc technique (pas de commentaire dans le code), programmée sans analyse (UML? Who needs that?), sans tests (il y a les clients pour cela), sans outil de debugage (à part celui intégré dans Delphi) et bien sûr sans contrôle de version...


    Je sens que j'ai du travail....

  11. #11
    Membre du Club
    Inscrit en
    avril 2003
    Messages
    79
    Détails du profil
    Informations forums :
    Inscription : avril 2003
    Messages : 79
    Points : 53
    Points
    53

    Par défaut

    Citation Envoyé par qi130
    - soit charger en 1er les tables référencées
    En fait sur le diagramme il y a des dependeances circulaires, donc là ça risque d'etre dur


    hum bizarre son schema
    Y a deux tables A et B qui sont reliées par leur propres clef primaires !!!
    A moins qu'il est voulu faire un heritage je vois pas trop l'interet.
    Ah ouf, apparement c'est ça lol

    La gestion des heritages en sgbdr c'est quand même pas joli.
    Avec des vues ça peut etre moins crade a l'utilisation, mais bon au niveau du model

  12. #12
    Membre du Club
    Inscrit en
    avril 2003
    Messages
    79
    Détails du profil
    Informations forums :
    Inscription : avril 2003
    Messages : 79
    Points : 53
    Points
    53

    Par défaut

    mmm en fait je pense qu'il a du avoir des problemes quand une table à un clef étrangere qui pointe sur ça propre clef primaire.
    Si les données sont pas chargées dans l'ordre ou si il y a un chainage circulaire, c'est coincé.

    Bref je lui dirais qu'il peut desactiver les contraintes

  13. #13
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 113
    Points
    113

    Par défaut

    J'ai trouvé un "livre blanc" qui dit grosso modo le contraire de l'opinion générale dans ce sujet, autrement dit qui dit que les règles d'intégrité référentielles devraient être traitées comme des règles métiers, et pas dans la base de données. Le cadre de ce livre blanc est la conception d'un couche d'accès aux données à travers des objets.

    Autre chose de troublant, c'est la suggestion d'abandonner, pour la création des clés, les données métier et d'utiliser que des GUIDS. Voici un extrait :

    Vous pouvez remarquer que la table Customer dans la figure précédente contient un champ qui n’a aucun équivalent dans le modèle objet. Il s’agit de la clé primaire : ID. Ce champ est de type GUID (General Unique Identifier), et représente de manière unique un enregistrement dans une table. Si par le passé vous définissiez vos clés primaires comme un ensemble de champs métiers de chaque table, c’était dans l’optique d’insérer une contrainte d’intégrité, et par exemple de confier au serveur de base de données la tâche de vérifier que deux enregistrements représentant la même entité logique ne puissent être insérés. Cette règle est typiquement une règle métier qui pourra être incluse dans la couche d’accès aux données, renvoyant une exception caractéristique par exemple. Dans l’optique de l’utilisation d’une couche d’accès aux données, les clés doivent être uniques, et n’avoir aucun sens vis-à-vis du métier qui est modélisé. Dans cette optique, les GUID sont la solution idéale.
    Que pensez-vous de tout cela ?

  14. #14
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 563
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 563
    Points : 30 071
    Points
    30 071

    Par défaut

    Les références circulaires ne sont pas un problème si le SGBDR considéré implémente la notion de déférabilité des donctraintes comme POSTGRESQL le fait.

    Sur le livre blanc et son optique d'IR non géré par le serveur qui trouble notre ami Promeneur...
    1) le mapping relationnel objet est la suite de l'abandon des SGBDOO qui ont fait long feu. C'est une technique intéressante mais peu utilisée.
    2) dans tous les cas elle suppose un outil de gestion de la persistance qui remplace ou se supperpose à l'IR, donc ajoute une couche de complexité et diminue les performances. (Et à quel coût !)
    3) l'utilisation d'un identifiant de type GUID est particulièrement contre performant par rapport à un entier taillé sur la longueur du mot du processeur (16 octets pour le GUID contre 4 pour le INTEGER, c'est donc plus de 4 fois moins rapide).

    Pour ma part mon expérience de l'objet dans le domaine des SGBD remonte à O² en 1993... Et depuis, rien de nouveau sous le soleil, c'est lourd, long, peu performant et encore mal maitrisé.

    je rajouterais pour terminé qu'une entreprise que je ne nommerais pas pour lui éviter une mauvaise publicité vendait ce concept de clef transversal unique au sein de toute la base en s'absolvant de la notion SQL d'IR et en le faisant par du code. C'était horriblement contre performant et comme la persistance était peu ou pas gérée, cela merdait à plein tube. Lorsque je suis allé auditer des applis avec ce genre de singerie c'était un régal... Et le client qui avait payé fort cher (beaucoup plus que la version classique) son dev, redevait payer pour la modif, car l'entreprise se retranchait derière des spécif allucinante du genre ; RAID 5 partout, onduleur ONLINE partout, cluster...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  15. #15
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juillet 2004
    Messages
    1 853
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 853
    Points : 3 182
    Points
    3 182

    Par défaut

    Bien qu'étant d'accord a priori avec SQLpro je voudrai juste faire remarquer que mysql ne supportait pas jusqu'à il n'y a pas longtemps, sauf erreur de ma part, l'intégrité référentielle.
    Je crois même que c'était un argument très fort justifiant les performances de cette base !!
    Aussi, même si je pense qu'il faut généralement faire gérer l'IR par la base, je ne serai pas catégorique comme l'ai SQLpro car des usages d'une base comme mysql risqueraient d'apporter de bons arguments contre la gestion de l'IR par la base....méfiance donc

  16. #16
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 113
    Points
    113

    Par défaut

    OK merci pour ces intéressantes réponses !

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •