Les OID (identificateurs d'objets)

Le modèle relationnel-objet permet de disposer d'identificateurs d'objet (OID[1]).

Une table objet dispose d'un OID pour chacun de ses tuples.

Caractéristiques

  • L'OID est une référence unique pour toute la base de données qui permet de référencer un enregistrement dans une table objet.

  • L'OID est une référence physique (adresse disque) construit à partir du stockage physique de l'enregistrement dans la base de données.

Avantages

  • Permet de créer des associations entre des objets sans effectuer de jointure (gain de performance).

  • Fournit une identité à l'objet indépendamment de ses valeurs (clé artificielle).

  • Fournit un index de performance maximale (un seul accès disque).

  • Permet de garder en mémoire des identificateurs uniques dans le cadre d'une application objet, et ainsi gérer la persistance d'objets que l'on ne peut pas garder en mémoire, avec de bonnes performances (alors que sinon il faudrait exécuter des requêtes SQL pour retrouver l'objet).

Inconvénient

  • Plus de séparation entre le niveau logique et physique.

  • L'adresse physique peut changer si le schéma de la table change (changement de la taille d'un champ par exemple)

  • Manipulation des données plus complexes, il faut un langage applicatif au dessus de SQL pour obtenir, stocker et gérer des OID dans des variables.

MéthodeCadre d'usage

L'usage d'OID est pertinent dans le cadre d'applications écrites dans un langage objet, manipulant un très grand nombre d'objets reliés entre eux par un réseau d'associations complexe.

En effet si le nombre d'objets est trop grand, les objets ne peuvent tous être conservés en mémoire vive par l'application objet qui les manipule. Il est alors indispensable de les faire descendre et remonter en mémoire régulièrement. Or dans le cadre d'un traitement portant sur de très nombreux objets, la remonté en mémoire d'un objet est un point critique en terme de performance. A fortiori si l'identification de l'objet à remonter demande une interrogation complexe de la BD, à travers de nombreuses jointures. Le fait d'avoir conservé en mémoire un OID permet de retrouver et de recharger très rapidement un objet, sans avoir à le rechercher à travers des requêtes SQL comportant des jointures et donc très couteuses en performance.

RemarqueDébat

  • La communauté des BD[2] est plutôt contre les OID, qui rompent avec la séparation entre manipulation logique et stockage physique des données.

  • La communauté objet est à l'origine de l'intégration des OID dans SQL3, en tant qu'ils sont une réponse au problème de persistance dans les applications objets.