Discussion :

[ez-95]

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

[pwrdwnsys]

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.

[ez-95]

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 ?

[escartefigue]

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