| Documentation PostgreSQL 8.0.25 | ||||
|---|---|---|---|---|
| Pr�c�dent | Arri�re rapide | Chapitre 5. D�finition des donn�es | Avance rapide | Suivant |
Chaque table a plusieurs colonnes syst�mes qui sont implicitement d�finis par le syst�me. De ce fait, ces noms ne peuvent �tre utilis�s comme noms de colonnes d�finis par l'utilisateur. (Notez que ces restrictions sont diff�rentes si le nom est un mot-cl� ou pas ; citez un nom ne vous permettra pas d'�chapper � ces restrictions.) Vous n'avez pas vraiment besoin de vous pr�occuper de ces colonnes, simplement savoir qu'elles existent.
L'identifiant objet (object ID) d'une rang�e. Ceci est un num�ro de s�rie qui est automatiquement rajout� par PostgreSQL � toutes les rang�es de tables (sauf si la table a �t� cr��e avec WITHOUT OIDS, auquel cas cette colonne n'est pas pr�sente). Cette colonne est de type oid (m�me nom que la colonne) ; voir la Section 8.12 pour plus d'informations sur ce type.
L' OID de la table contenant cette rang�e. Cette colonne est particuli�rement utile pour les requ�tes qui s�lectionnent de hi�rarchies h�rit�es, puisque sans elle, il est difficile de dire de quelle table vient une rang�e. tableoid peut �tre joint � la colonne oid de pg_class pour obtenir le nom de la table.
L'identit� (transaction ID) de la transaction d'insertion de cette version de la rang�e. (Une version de rang�e est un �tat individuel d'une rang�e; chaque mise � jour d'une rang�e cr�e une nouvelle version de rang�e pour la m�me rang�e logique.)
L'identifiant de commande (� partir de z�ro) au sein de la transaction d'insertion.
L'identit� (transaction ID) de la transaction de suppression, ou z�ro pour une version de rang�e non effac�e. Il est possible pour cette colonne d'�tre non NULL dans une version de rang�e visible: Ceci indique normalement que la transaction de suppression n'a pas �t� effectu�e, ou qu'une tentative de suppression a �t� annul�e.
L'identifiant de commande au sein d'une transaction de suppression, ou z�ro.
La localisation physique de la version de rang�e au sein de sa table. Notez que bien que le ctid peut �tre utilis� pour trouver la version de rang�e tr�s rapidement, le ctid d'une rang�e changera chaque fois qu'il est mis � jour ou d�plac� par la commande VACUUM FULL. Donc, ctid est inutile en tant qu'identifiant de rang�e � long terme. L'OID, ou encore mieux un num�ro de s�rie d�finie par l'utilisateur, devrait �tre utilis� pour identifier des rang�es logiques.
Les OID sont des nombres de 32 bits et sont attribu�s d'un seul compteur. Dans une base de donn�es grande ou vieille, il est possible que le compteur boucle sur lui-m�me. Donc il est peu pertinent de partir du principe que les OID sont uniques, sauf si vous prenez les pr�cautions n�cessaires. Si vous avez besoin d'identifier les lignes dans une table, l'utilisation d'un g�n�rateur de s�quence est fortement recommand�e. N�anmoins, les OID peuvent aussi �tre utilis�s � condition que quelques pr�cautions soient prises :
Une contrainte unique devrait �tre cr��e sur la colonne OID de chaque table pour laquelle l'OID sera utilis�e pour identifier les lignes.
Les OID ne devraient jamais �tre suppos�s uniques entre tables ; utilisez la combinaison de tableoid et de l'OID de la ligne si vous avez besoin d'un identifiant sur la base compl�te.
Les tables en question devraient �tre cr��es en utilisant WITH OIDS pour s'assurer de la compatibilit� avec les versions futures de PostgreSQL. Il est planifi� que WITHOUT OIDS deviendra l'option par d�faut.
Les identifiants de transaction sont aussi des nombres de 32 bits. Dans une base de donn�es de longue vie, il est possible pour les ID de transaction de boucler sur eux-m�mes. Ceci n'est pas un probl�me fatal avec des proc�dures de maintenance appropri�es; voir le Chapitre 21 pour les d�tails. Il est, par contre, imprudent de d�pendre de l'aspect unique des ID de transaction � long terme (plus d'un milliard de transactions).
Les identifiants de commande sont aussi des nombres de 32 bits. Ceci cr�e une limite dure de 232 (4 milliards) commandes SQL au sein d'une seule transaction. En pratique, cette limite n'est pas un probl�me — notez que la limite est sur le nombre de commandes SQL, pas le nombre de rang�es trait�es.
| Pr�c�dent | Sommaire | Suivant |
| Contraintes | Niveau sup�rieur | H�ritage |