Documentation PostgreSQL 8.0.25 | ||||
---|---|---|---|---|
Pr�c�dent | Arri�re rapide | Chapitre 5. D�finition des donn�es | Avance rapide | Suivant |
Cr�ons deux tables. La table capitales contient les capitales d'�tat qui sont aussi des villes. Naturellement, la table capitales doit h�riter de villes.
CREATE TABLE villes ( nom text, population float, altitude int -- (in ft) ); CREATE TABLE capitales ( etat char(2) ) INHERITS (villes);
Dans ce cas, une rang�e de capitales h�rite de tous les attributs (nom, population, et altitude) de son parent villes. Les capitales d'�tat ont un attribut suppl�mentaire state qui donne leur �tat. Dans PostgreSQL, une table peut h�riter de z�ro tables ou plus et une requ�te peut r�f�rencer toutes les rang�es d'une table ou toutes les rang�es d'une table plus celles de ses descendants.
Note�: La hi�rarchie d'h�ritage est en fait un graphe acyclique dirig�.
Par exemple, la requ�te suivante cherche les noms de toutes les villes, y compris les capitales d'�tat, qui se situent � une altitude de plus de 500 pieds:
SELECT nom, altitude FROM villes WHERE altitude > 500;
qui retourne:
nom | altitude -----------+---------- Las Vegas | 2174 Mariposa | 1953 Madison | 845
D'un autre c�t�, la requ�te suivante cherche toutes les villes qui ne sont pas des capitales d'�tat et qui sont situ�s � une altitude de plus de 500 pieds:
SELECT nom, altitude FROM ONLY villes WHERE altitude > 500; nom | altitude -----------+---------- Las Vegas | 2174 Mariposa | 1953
Ici, le <<�ONLY�>> avant villes indique que la requ�te ne devrait �tre lanc�e que sur villes et non les tables en dessous de villes dans la hi�rarchie d'h�ritage. Beaucoup des commandes donc nous avons d�j� discut� -- SELECT, UPDATE et DELETE -- g�rent cette syntaxe <<�ONLY�>>.
Obsol�te�: Dans les pr�c�dentes versions de PostgreSQL, le comportement par d�faut �tait de ne pas inclure les tables enfants dans les requ�tes. Il a �t� prouv� que cela amenait facilement des erreurs et est aussi en violation du standard SQL:1999. Avec l'ancienne syntaxe, pour obtenir les sous-tables, vous ajoutez * au nom de la table. Par exemple
SELECT * from villes*;Vous pouvez toujours sp�cifi� explicitement le parcours des tables enfants en ajoutant *, ainsi qu'en sp�cifiant explicitement les tables enfants en �crivant <<�ONLY�>>. Mais, depuis la version 7.1, le comportement par d�faut pour un nom de table non d�cor� est de parcourir aussi ses tables enfants alors qu'avant ce n'�tait pas le comportement par d�faut. Pour obtenir l'ancien comportement par d�faut, initialisez l'option de configuration SQL_Inheritance � off, ainsi
SET SQL_Inheritance TO OFF;ou ajoutez une ligne dans votre fichier postgresql.conf.
Dans certain cas, vous souhaiterez savoir dans quel table provient une rang�e donn�e. Il y a une colonne syst�me appel�e TABLEOID dans chaque table qui peut vous donner la table d'origine:
SELECT c.tableoid, c.nom, c.altitude FROM villes c WHERE c.altitude > 500;
qui renvoie :
tableoid | name | altitude ----------+-----------+---------- 139793 | Las Vegas | 2174 139793 | Mariposa | 1953 139798 | Madison | 845
(Si vous essayez de reproduire cet exemple, vous obtiendrez probablement des OID num�riques diff�rents.) En faisant une jointure avec pg_class, vous pourrez voir les noms de tables actuelles:
SELECT p.relname, v.nom, v.altitude FROM villes v, pg_class p WHERE v.altitude > 500 and v.tableoid = p.oid;
ce qui retourne:
relname | nom | altitude -----------+-----------+---------- villes | Las Vegas | 2174 villes | Mariposa | 1953 capitales | Madison | 845
Une table peut tr�s bien h�riter de plusieurs tables. Dans ce cas-l�, les colonnes de la table fille correspondent � l'union des colonnes provenant des tables parentes et des colonnes d�finies dans la table fille.
Une limitation s�rieuse de la fonctionnalit� d'h�ritage est que les index (incluant les contraintes uniques) et les contraintes de cl�s �trang�res s'appliquent seulement � des tables seules, pas � leurs h�ritiers. Ceci est vrai pour le c�t� de r�f�rence et le c�t� r�f�renc� d'une contrainte de cl� �trang�re. Du coup, dans les termes de l'exemple ci-dessus :
Si nous d�clarons villes.nom comme UNIQUE ou comme une PRIMARY KEY, ceci n'emp�chera pas la table capitales d'avoir des lignes avec des noms dupliqu�s dans villes. Et ces lignes dupliqu�es pourraient par d�faut s'afficher dans les requ�tes sur villes. En fait, par d�faut, capitales n'aurait pas du tout de contrainte unique et, du coup, pourrait contenir plusieurs lignes avec le m�me nom. Vous pouvez ajouter une contrainte unique � capitales mais ceci n'emp�cherait pas la duplication compar�e � villes.
De fa�on similaire, si nous devions sp�cifier que villes.nom REFERENCES une autre table, cette contrainte ne serait pas automatiquement propager � capitales. Dans ce cas, vous pourriez contourner ceci en ajoutant manuellement la m�me contrainte REFERENCES � capitales.
Sp�cifier que la colonne d'une autre table REFERENCES villes(nom) autoriserait l'autre table � contenir les noms des villes mais pas les noms des capitales. Il n'existe pas de bons contournements pour ce cas.
Ces d�ficiences seront probablement corrig�es dans une future version mais en attendant, un soucis consid�rable est n�cessaire dans la d�cision de l'utilit� de l'h�ritage pour votre probl�me.
Pr�c�dent | Sommaire | Suivant |
Colonnes Syst�mes | Niveau sup�rieur | Modification des tables |