FirebirdSQL logo
 Gestion des opérateurs de contrôleTraitement des erreurs, codes et messages 

Pseudo-colonne RDB$DB_KEY

Chaque table et vue contient une pseudo-colonne RDB$DB_KEY.

La colonne RDB$DB_KEY est une clé interne qui indique la position d’un enregistrement dans une table. Elle est maintenue par le serveur de base de données pour un usage interne et peut être utilisée par vous dans certains cas comme le moyen le plus rapide de trouver un enregistrement dans une table.

RDB$DB_KEY est un pointeur logique vers une entrée de la table, et en aucun cas vers une adresse physique sur le disque. Les valeurs de RDB$DB_KEY ne suivent pas une séquence prévisible, donc n’essayez pas d’utiliser directement des calculs impliquant leurs positions relatives. Cela ne peut être fait qu’avec la fonction MAKE_DBKEY.

Important

Les valeurs de RDB$DB_KEY ne sont pas stables.Ils sont modifiés après une sauvegarde et une restauration ultérieure, et parfois après la confirmation d’une transaction.Par conséquent, considérez RDB$DB_KEY comme une valeur éphémère et n’essayez pas de l’utiliser lorsque la transaction au cours de laquelle elle a été reçue est terminée ou annulée.

Taille RDB$DB_KEY

Pour les tables, le champ RDB$DB_KEY utilise 8 octets et est de type BINARY(8). Pour les vues, le champ RDB$DB_KEY utilise une taille de 8 octets fois le nombre de tablesutilisées dans la vue. Par exemple, si une vue joint trois tables, la RDB$DB_KEY utilise 24 octets. Ceci est important lorsque vous travaillez avec des modules PSQL et que vous avez l’intention de stocker RDB$DB_KEY dans des variables. Vous devez utiliser le type de données BINARY(n) de la bonne longueur. La valeur exacte de la longueur du champ RDB$DB_KEY peut être trouvée en utilisant la table système RDB$RELATIONS. Il est stocké dans le champ RDB$DBKEY_LENGTH.

Example 1. Détermination de la longueur de la RDB$DB_KEY pour la vue V_FARM.
SELECT
  RDB$DBKEY_LENGTH
FROM RDB$RELATIONS
WHERE RDB$RELATION_NAME = 'V_FARM'

Utilisation de la clé RDB$DB_KEY

Puisque RDB$DB_KEY pointe directement vers l’endroit où l’enregistrement est stocké, la recherche sera plus rapide qu’avec une clé primaire. Si, pour une raison quelconque, la table n’a pas de clé primaire ou d’index unique actif, ou si l’index unique autorise les valeurs NULL, il est possible que des enregistrements en double existent. Dans ces circonstances, RDB$DB_KEY est le seul moyen d’identifier précisément chaque enregistrement.

Le serveur Firebird utilise RDB$DB_KEY pour optimiser certaines méthodes d’accès. Par exemple, pour optimiser le tri externe. Si la largeur des enregistrements à trier est très grande (dépasse la valeur spécifiée dans le paramètre de configuration InlineSortThreshold), alors au lieu du tri externe classique, seul le tri par clé est utilisé, en sauvegardant RDB$DB_KEY pour les tables liées, et en effectuant ensuite un Refetch pour récupérer les enregistrements de ces tables en utilisant le RDB$DB_KEY sauvegardé.

Une autre utilisation de RDB$DB_KEY et de la fonction MAKE_DBKEY est de diviser les grandes tables en parties à peu près égales, ce qui est utilisé dans les sauvegardes parallèles.

Example 2. Diviser une grande table en plusieurs parties
-- Récupérer les données de la table SOMETABLE contenues dans les pages de données (DP),
-- désignées par la première page de pointeurs (PP).
select * from SOMETABLE
where rdb$db_key >= make_dbkey('SOMETABLE', 0, 0, 0)
  and rdb$db_key <  make_dbkey('SOMETABLE', 0, 0, 1);

-- Récupérer les données de la table SOMETABLE contenues dans les pages de données (DP),
-- désignées par la deuxième page de pointeurs (PP).
select * from SOMETABLE
where rdb$db_key >= make_dbkey('SOMETABLE', 0, 0, 1)
  and rdb$db_key <  make_dbkey('SOMETABLE', 0, 0, 2);

...

Durée de vie de RDB$DB_KEY

Par défaut, la portée de RDB$DB_KEY est la transaction courante. Vous pouvez supposer qu’elle reste correcte tant que la transaction courante est en cours. Confirmer ou annuler une transaction rendra les valeurs de RDB$DB_KEY imprévisibles. Si vous utilisez COMMIT RETAINING, le contexte de la transaction est préservé, ce qui bloque la collecte des déchets et empêche donc l’ancienne clé_db d’être "réaffectée". Dans ces conditions, les valeurs RDB$DB_KEY pour tous les enregistrements utilisés dans votre transaction sont maintenues valides jusqu’à ce qu’une validation "forcé"(commit) ou un rollback se produise.

Après une validation(commit) ou un retour en arrière(rollback), une autre transaction peut supprimer un enregistrement qui a été isolé dans le contexte de votre transaction et donc traité comme "existant" dans votre application. Toute valeur RDB$DB_KEY peut maintenant pointer vers un enregistrement inexistant ou vers un autre enregistrement placé à cet endroit.