Je crée une table de démonstration simple dans Derby en utilisant ce ddl:
CREATE TABLE MY_TABLE (
SESSION_ID CHAR(36),
ATTRIBUTE_NAME VARCHAR(200),
CONSTRAINT MY_TABLE_PK PRIMARY KEY (SESSION_ID, ATTRIBUTE_NAME),
);
CREATE INDEX MY_TABLE_IX1 ON MY_TABLE (SESSION_ID);
Je veux vérifier sur un test si le code INDEX MY_TABLE_IX1
a été créé.
En recherchant en ligne, je vois 2 méthodes possibles pour y parvenir:
JDBC ->
En utilisant DatabaseMetaData
je peux faire quelque chose dans le sens de
metadata.getIndexInfo(null, "APP", "MY_TABLE", false, false)
Itérer sur le jeu de résultats jusqu'à ce que j'obtienne une ligne où
"MY_TABLE_IX1".equals(resultSet.getString("INDEX_NAME"))
SQL ->
SELECT c.CONGLOMERATENAME, t.TABLENAME FROM SYS.SYSCONGLOMERATES c
JOIN SYS.SYSTABLES t ON c.TABLEID = t.TABLEID
WHERE c.CONGLOMERATENAME = 'MY_TABLE_IX1' AND t.TABLENAME = 'MY_TABLE'
En laissant de côté l'évidence (comme je devrais aussi filtrer par nom de colonne, etc.), je rencontre un comportement très étrange:
Derby enregistre certains de mes index sous forme de chaînes de la forme SQL181215003216931
, ce qui ne me permet pas de localiser ces index par nom, tandis que les autres index sont enregistrés sous le nom spécifié dans mon ddl.
Bien que j’aie donné un petit exemple, mon schéma actuel est assez volumineux, et si j’exécute ce qui suit:
SELECT c.CONGLOMERATENAME, t.TABLENAME FROM SYS.SYSCONGLOMERATES c
JOIN SYS.SYSTABLES t ON c.TABLEID = t.TABLEID
WHERE c.CONGLOMERATENAME LIKE '%SQL%'
J'obtiens un assez gros résultat d'indices nommés de la même manière (ils diffèrent par les nombres finaux après la partie SQL
) bien que je leur ai donné un nom significatif.
J'ai essayé de parcourir le Web pour trouver des informations sur ce comportement, mais je suis resté vide. Quelqu'un connaît-il la réponse à mon mystère?
Il semble que les noms de type SQL####
ne renvoient pas aux noms que j’avais donnés à l’origine, alors comment puis-je localiser mes index en fonction de my names?
Voici un exemple de sortie de la deuxième requête SQL:
CONGLOMERATENAME TABLENAME
------------------------------------
SQL181215003159230 MY_TABLE
SQL181215003159240 SOME_OTHER_TABLE
SQL181215003216890 YET_ANOTHER_TABLE
Et à partir de l'exécution de JDBC:
TABLE_CAT|TABLE_SCHEMA|TABLE_NAME |NON_UNIQUE|INDEX_QUALIFIER|INDEX_NAME |TYPE|ORDINAL_POSITION|COLUMN_NAME|ASC_OR_DESC|CARDINALITY|PAGES|FILTER_CONDITION|
|APP |MY_TABLE |false | |SQL181224003626061|3 |1 |SESSION_ID |A |null |null |null |
|APP |SOME_OTHER_TABLE |false | |SQL181215003159240|3 |1 |SESSION_ID |A |null |null |null |
--- Edit ----: D'après la réponse de @Noam ci-dessous, il semble qu'il est correct et que les index SQL###
sont bien des clés primaires et que les index sont définis sur des colonnes de clé primaire (bien que ce soit fondamentalement injustifié, ).
Mon problème reste que je dois savoir si cet index que j'ai déclaré avec un nom spécifique - et ce nom est introuvable.
SQL*
sont les index uniques/primaires configurés directement dans la définition de la table, comme le MY_TABLE_PK
Selon leur documentation ( https://db.Apache.org/derby/docs/10.1/ref/rrefsqlj13590.html ), vous devriez pouvoir trouver les index des contraintes que vous pouvez utiliser cette requête modifications mineures à la requête ici):
SELECT * FROM SYS.SYSCONSTRAINTS t
JOIN SYS.SYSCONGLOMERATES c ON t.TABLEID = c.TABLEID
WHERE CONSTRAINTNAME = 'MY_TABLE_PK';
Mon problème reste que je dois savoir si cet index que j'ai déclaré avec un nom spécifique - et ce nom est introuvable.
Je viens de tester avec DBeaver et derby-10.14.2.0.jar et j'ai constaté que, comme le mentionne @Noam, "MY_TABLE_PK" est répertorié dans SYS.SYSCONSTRAINTS.
SELECT * FROM SYS.SYSCONSTRAINTS WHERE CONSTRAINTNAME='MY_TABLE_PK'
et "MY_TABLE_IX1" est répertorié dans SYS.SYSCONGLOMERATES
SELECT * FROM SYS.SYSCONGLOMERATES WHERE CONGLOMERATENAME='MY_TABLE_IX1'