1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    février 2017
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : février 2017
    Messages : 2
    Points : 1
    Points
    1

    Par défaut Besoin d'éclairage sur index DB2/AS400

    Bonjour,
    Je ne suis pas DBA ni développeur, mais un fonctionnel techniquement réceptif ...
    Je démarre une mission chez un client qui utilise DB2 AS400 en version 7.1
    La situation de la base est désastreuse.
    Il n'y a aucune clé primaire, et aucune clé étrangère.
    Il y a par contre un certain nombre d'index unique qui assurent un minimum d'intégrité, j'ai bien dit un minimum.
    Sur une table, mais il y en a surement d'autres dans le modèle, je trouve une définition d'index qui ne colle pas avec le contenu.
    Je ne connais pas les spécificités ou différences de DB2/iSerie par rapport à Oracle que je connais mieux, et j'aimerai avoir un éclairage.

    Dans cette table, les index sont les suivants :
    CREATE UNIQUE INDEX INDEXL1 ON SCHEMA.TABLE (CODE1,CODE2) ;
    CREATE INDEX INDEXL2 ON SCHEMA.TABLE (CODE2,CODE1) ;
    CREATE INDEX INDEXL3 ON SCHEMA.TABLE (CODE3,CODE1) ;
    CREATE UNIQUE INDEX INDEXL4 ON SCHEMA.TABLE (CODE1) ;

    Le contenu de la table est :
    CODE1 CODE2 CODE3
    ABCD 1234
    ABCD 2345
    ABCD 3456 abcd
    DEFG 3456
    DEFG 7890 bcde
    etc...

    L'assemblage de CODE1 et CODE2,qui sont toujours servis, forme effectivement un identifiant unique qui devrait être la clé primaire.
    L'index INDEXL1 est cohérent avec le contenu, et un tentative d'écriture d'une nouvelle ligne avec un couple déjà présent sort bien en erreur "Duplicate Key".
    Les index INDEXL2 et INDEXL3 ne me posent pas de problème de compréhension, pour la pertinence je verrais plus tard
    L'index INDEXL4 me pose un problème car tel qu'il est dans le DDL généré, il n'est pas applicable.

    Dans mes souvenirs, un index UNIQUE crée une contrainte d'unicité.
    Toujours dans mes souvenirs, une contrainte peut s'activer ou se désactiver, pour optimiser un batch par exemple, et donc rester inactivée volontairement ou non.

    Question 1 : mon analyse est-elle valable sur ce SGBDR ?
    Question 2 : si Oui, comment peut-on visualiser l'état des contraintes avec iNavigator ou DBeaver
    Question 3 : et si Non, ou est mon erreur

    Merci

  2. #2
    Membre habitué
    Homme Profil pro
    Architecte technique
    Inscrit en
    septembre 2010
    Messages
    110
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Santé

    Informations forums :
    Inscription : septembre 2010
    Messages : 110
    Points : 154
    Points
    154

    Par défaut

    Bonjour.

    A priori, on peut partir du principe que UNIQUE INDEX s'apparente à une clé primaire. Par contre, on ne peut pas activer/désactiver cette contrainte à la demande.
    On doit pouvoir voir l'état des tables dans iNavigator (probablement sur les propriétés de la table), mais je n'utilise pas trop. Il y a des vues système (QSYS2.SYSCST*) qui permettent de voir tout cela par requête SQL.

    L'index L4 ne sert absolument à rien, il est redondant avec le L1 : une clé dupliquée dans le L1 sera forcément dupliquée dans le L4. Et même pour les optimisations, le L4 ne sert à rien, puisqu'il est possible de passer par le L1. J'aurais tendance à supprimer le L4 (qui ralentit les mises à jour, du coup).

    Les L2 et L3 sont probablement là pour permettre à des programmes natifs (RPG ou COBOL) de lire la table dans un ordre différent de la clé primaire. N'oublions pas que sur un i, les programmeurs qui font des accès natifs se fabriquent des index pour cela, alors que maintenant, il vaudrait mieux passer par du SQL embarqué et créer uniquement des index d'optimisation.

  3. #3
    Nouveau Candidat au Club
    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    février 2017
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : février 2017
    Messages : 2
    Points : 1
    Points
    1

    Par défaut

    Bonjour PW...SYS, et merci pour ta réponse rapide.

    Ton analyse me rassure car elle correspond à la mienne :
    - effectivement il serait plus judicieux de définir une clé primaire composée de CODE1-CODE2, ce qui ne donnerait plus aucune plus value à INDEXL1
    - effectivement INDEXL4 ne sert à rien puisque dans l'état actuel il est quasi redondant avec INDEXL1
    - INDEXL2 et INDEXL3 sont probablement utilisés par d'autres programmes pour des besoins spécifiques, et ne me posent pas de question

    Ce qui me gène en revanche, c'est que c'est une base active et que le contenu de la table (suivant l'exemple que j'ai décrit) n'est pas en cohérence avec la description de INDEXL4.

    Vu le contenu actuel, INDEXL4 ne peut pas être un index UNIQUE car CODE1 seul n'est pas discriminant, il y a des doublons.

    C'est pour cette raison que je pensais à un problème d'activation de la contrainte.

    Lors d'une mission précédente, sous ORACLE, nous avions été confrontés a des problèmes de performance sur des gros batchs de déchargement / rechargement.
    Les DBA avaient mis en place une désactivation de toutes contraintes de certaines tables avant traitement, suivi d'une réactivation après traitement.
    C'était, il me semble, avec la commande ALTER TABLE DISABLE CONSTRAINT XXXX, et donc une ligne par contrainte à désactiver
    Du coup, si à la sortie une ligne était omise pour les réactivation (volontairement ou non), la contrainte avait beau être présente dans la description de la table, ses règles n'étaient pas activées.

    C'est ce que je soupçonne dans mon cas actuel, mais je ne sais pas comment le confirmer.

    Est-ce que DB2/iSerie permet aussi ce type de commande (ALTER TABLE DISABLE/ENABLE CONSTRAINT XXXX) ?
    Comment visualiser l'état courant d'une contrainte ?

  4. #4
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 516
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 516
    Points : 5 626
    Points
    5 626

    Par défaut

    Citation Envoyé par pwrdwnsys Voir le message
    A priori, on peut partir du principe que UNIQUE INDEX s'apparente à une clé primaire
    Attention toutefois à la différence fondamentale entre identifiant Primaire et identifiant unique : si l'un et l'autre sont uniques, le premier est obligatoirement non nul, contrairement au second

Discussions similaires

  1. Besoin d'éclairage sur fork()
    Par Arkenis dans le forum Débuter
    Réponses: 2
    Dernier message: 30/04/2012, 15h11
  2. neophyte besoin d'éclairage sur les visual basic ?
    Par tibofo dans le forum Visual Studio
    Réponses: 4
    Dernier message: 26/06/2009, 13h56
  3. Réponses: 3
    Dernier message: 19/06/2008, 20h39
  4. Question sur index DB2 400
    Par Jibon dans le forum DB2
    Réponses: 4
    Dernier message: 19/08/2007, 17h58
  5. Besoin d'éclairage sur une applet
    Par cassboul dans le forum Applets
    Réponses: 4
    Dernier message: 01/08/2006, 19h33

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo