base de données H2: Information sur la clé primaire dans INFORMATION_SCHEMA

Question

Je crée le tableau suivant dans H2:

CREATE TABLE TEST
(ID BIGINT NOT NULL PRIMARY KEY)

Alors je regarde dans la table INFORMATION_SCHEMA.TABLES:

SELECT SQL 
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'TEST'

Résultat:

CREATE CACHED TABLE TEST(
    ID BIGINT NOT NULL
)

Alors je regarde dans la table INFORMATION_SCHEMA.CONSTRAINTS:

SELECT SQL 
FROM INFORMATION_SCHEMA.CONSTRAINTS
WHERE TABLE_NAME = 'TEST'

Résultat:

ALTER TABLE TEST 
ADD CONSTRAINT CONSTRAINT_4C 
PRIMARY KEY(ID) 
INDEX PRIMARY_KEY_4C

Ces déclarations ne sont pas celles que je l'ai dit, la question est donc: L'information dans les tableaux et CONTRAINTES reflète la façon dont SQL réel qui a été exécuté dans la base de données?

1. dans l'original CREATE TABLE il n'y avait pas CACHED mot. (Pas un problème)
2. Je n'ai jamais exécuté ALTER TABLE .. ADD CONSTRAINT déclaration.

La vraie raison pour laquelle je pose la question est que je ne suis pas sûr quelle déclaration dois-je exécuter pour garantie que la clé primaire est utilisée dans un index ordonné en clusters. Si vous regardez ma question précédente base de données H2: support index ordonné en clusters alors vous pouvez trouver dans la réponse de Thomas Mueller la déclaration suivante:

Si une clé primaire est créé après la table a été créé alors la clé primaire est stockée dans un nouvel index b-tree.

Par conséquent, si les instructions sont exécutées en tant que tels qu'ils sont présentés dans INFORMATION_SCHEMA, puis la clé primaire est créée après la table est créée et, par conséquent ID n'est pas utilisé dans un index ordonné en clusters (essentiellement comme une clé dans un b-arbre de données) .

Est-il possible comment on peut garantir que la clé primaire est utilisée dans un index ordonné en clusters dans H2?

Answer 1

  

L'information dans les tableaux et CONTRAINTES reflète la façon dont SQL réel qui a été exécuté dans la base de données?

Oui. En fait, ce sont les déclarations qui sont exécutées lors de l'ouverture de la base de données.

  

Si vous regardez ma question précédente

La réponse « Si une clé primaire est créée après la table a été créée ... » était incorrect, je fixe maintenant à « Si une clé primaire est créé après des données a été inséré ... ».

  

Est-il possible comment on peut garantir que la clé primaire est utilisé comme index ordonné en clusters dans H2?

Ceci est mieux maintenant décrit dans le documentation H2 sur « Comment les données sont stockées en interne « : » Si une seule colonne clé primaire de type BIGINT, INT, SMALLINT, TINYINT est spécifié lors de la création de la table (ou juste après la création de la table, mais avant d'insérer toutes les lignes), cette colonne est utilisée comme la clé des données b-arbre. "