Changeset 1092
- Timestamp:
- 07/08/08 12:52:44 (5 months ago)
- Files:
-
- traduc/trunk/postgresql/ddl.xml (modified) (73 diffs)
- traduc/trunk/postgresql/docguide.xml (modified) (19 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
traduc/trunk/postgresql/ddl.xml
r973 r1092 4 4 par $Author$ 5 5 révision $Revision$ --> 6 <!-- SAS : 20070410, PG 8.2.3 -->7 6 8 7 <chapter id="ddl"> … … 51 50 <para> 52 51 De plus, le SQL n'attribue pas d'identifiant unique aux lignes. Il est 53 donc possible 54 d'avoir plusieurs lignes identiques au sein d'une table. C'est une 55 conséquence du modèle mathématique sur lequel repose le SQL, même si 56 cela n'est habituellement pas souhaitable. 52 donc possible d'avoir plusieurs lignes identiques au sein d'une table. 53 C'est une conséquence du modèle mathématique sur lequel repose le SQL, 54 même si cela n'est habituellement pas souhaitable. 57 55 Il est expliqué plus bas dans ce chapitre comment traiter ce problème. 58 56 </para> 59 57 60 58 <para> 61 Chaque colonne a un type de donnée . Ce type de donnée limite l'ensemble59 Chaque colonne a un type de données. Ce type limite l'ensemble 62 60 de valeurs qu'il est possible d'attribuer à une colonne. Il attribue 63 61 également une sémantique aux données stockées dans la colonne pour … … 142 140 </tip> 143 141 144 <!-- Par contre, utilisé par Céline dans un souci de provocation, n'est à 145 l'évidence pas une construction grammaticale préconisée par l'Académie 146 Française. On lui préférera "En revanche", "Cependant", "Au contraire"... --> 142 <!-- Par contre, utilisé par Céline (pas Dion, mais Louis-Ferdinand) dans un 143 souci de provocation, n'est à l'évidence pas une construction grammaticale 144 préconisée par l'Académie Française. On lui préférera "En revanche", 145 "Cependant", "Au contraire"... --> 147 146 <para> 148 147 Le nombre de colonnes d'un table est limité. En fonction du type de … … 168 167 d'erreur sont alors ignorés afin que le script fonctionne que la table 169 168 existe ou non. (La variante <literal>DROP TABLE IF EXISTS</literal> peut 170 aussi être utilisée pour 171 éviter les messages d'erreur mais elle ne fait pas partie du 169 aussi être utilisée pour éviter les messages d'erreur mais elle ne fait pas partie du 172 170 standard SQL.) 173 171 </para> … … 182 180 fonctionnelles. Le reste de ce chapitre est consacré à l'ajout de fonctionnalités 183 181 à la définition de tables pour garantir l'intégrité des données, la sécurité 184 ou l'ergonomie. Le lecteur impatient d'insérer des données dans ses tables182 ou l'ergonomie. Le lecteur impatient d'insérer des données dans ses tables 185 183 peut sauter au <xref linkend="dml"/> et lire le reste de 186 184 ce chapitre plus tard. … … 296 294 générique qui soit. Elle permet d'indiquer que la valeur 297 295 d'une colonne particulière doit satisfaire une expression booléenne 298 (valeur de vérité). Par 299 exemple, pour obliger les prix des produits à être positifs, on peut 300 utiliser : 296 (valeur de vérité). Par exemple, pour obliger les prix des produits 297 à être positifs, on peut utiliser : 301 298 <programlisting>CREATE TABLE produits ( 302 299 no_produit integer, … … 363 360 <para> 364 361 Les deux premières contraintes sont appelées contraintes de 365 colonne standis que la troisième est appelée contrainte de table parce362 colonne tandis que la troisième est appelée contrainte de table parce 366 363 qu'elle est écrite séparément d'une définition de colonne particulière. 367 Les contraintes de colonne speuvent être écrites comme des contraintes de368 table s, mais l'inverse n'est pas forcément possible puisqu'une contrainte de colonne est364 Les contraintes de colonne peuvent être écrites comme des contraintes de 365 table, mais l'inverse n'est pas forcément possible puisqu'une contrainte de colonne est 369 366 supposée ne faire référence qu'à la colonne à laquelle elle est 370 367 attachée (<productname>PostgreSQL</productname> ne vérifie pas cette règle … … 455 452 456 453 <para> 457 Une colonne peut évidemment avoir plus d'une contrainte. Il suffit454 Une colonne peut évidemment avoir plusieurs contraintes. Il suffit 458 455 d'écrire les contraintes les unes après les autres : 459 456 <programlisting>CREATE TABLE produits ( … … 470 467 <literal>NULL</literal>. Elle ne signifie pas que la colonne doit 471 468 être NULL, ce qui est assurément inutile, mais sélectionne le comportement 472 par défaut, à savoir que la colonne peut être NULL. La contrainte <literal>NULL473 < /literal> n'est pas présente dans le standard SQL et ne doit pas469 par défaut, à savoir que la colonne peut être NULL. La contrainte 470 <literal>NULL</literal> n'est pas présente dans le standard SQL et ne doit pas 474 471 être utilisée dans des applications portables (elle n'a été ajoutée 475 472 dans <productname>PostgreSQL</productname> que pour assurer la 476 473 compatibilité avec d'autres bases de données). Certains utilisateurs 477 474 l'apprécient néanmoins car elle permet de basculer aisément d'une 478 contrainte à l'autre dans un fich eir de script. On peut, par exemple, commencer avec :475 contrainte à l'autre dans un fichier de script. On peut, par exemple, commencer avec : 479 476 <programlisting>CREATE TABLE produits ( 480 477 no_produit integer NULL, … … 487 484 <tip> 488 485 <para> 489 Dans la plupart des bases de données, la majorité des490 colonnes peut être marquéeNOT NULL.486 Dans la plupart des bases de données, il est préférable que la majorité des 487 colonnes soient marquées NOT NULL. 491 488 </para> 492 489 </tip> … … 620 617 621 618 <para> 622 Une table a au plusune clé primaire. (Le nombre de contraintes UNIQUE NOT NULL,619 Une table a, au plus, une clé primaire. (Le nombre de contraintes UNIQUE NOT NULL, 623 620 qui assurent la même fonction, n'est pas limité, mais une seule 624 621 peut être identifiée comme clé primaire.) La théorie des … … 699 696 Une clé étrangère peut aussi contraindre et référencer un groupe de colonnes. 700 697 Comme cela a déjà été évoqué, il faut alors l'écrire sous forme d'une contrainte de table. 701 Voici un exemple de syntaxe :698 Exemple de syntaxe : 702 699 <programlisting>CREATE TABLE t1 ( 703 700 a integer PRIMARY KEY, … … 985 982 compteur unique sur le cluster. Dans une base de données volumineuse ou 986 983 agée, il est possible que le compteur boucle. Il est de ce fait peu 987 pertinent de 988 considérer que les OID puissent être uniques ; pour identifier les 989 lignes d'une table, il est fortement 990 recommandé d'utiliser un générateur de séquence. 991 Néanmoins, les OID peuvent également être utilisés sous réserve que quelques 992 précautions soient prises : 984 pertinent de considérer que les OID puissent être uniques ; pour 985 identifier les lignes d'une table, il est fortement recommandé d'utiliser 986 un générateur de séquence. Néanmoins, les OID peuvent également être 987 utilisés sous réserve que quelques précautions soient prises : 993 988 994 989 <itemizedlist> … … 1042 1037 De plus, à partir de <productname>PostgreSQL</productname> 8.3, seules les 1043 1038 commandes qui modifient réellement le contenu de la base de données 1044 consomme ront un identifiant de commande.1039 consomment un identifiant de commande. 1045 1040 </para> 1046 1041 </sect1> … … 1109 1104 1110 1105 <para> 1111 La commande d'ajout d'une colonne ressemble à celle-ci :1106 La commande d'ajout d'une colonne ressemble à : 1112 1107 <programlisting>ALTER TABLE produits ADD COLUMN description text;</programlisting> 1113 1108 La nouvelle colonne est initialement remplie avec la valeur par défaut … … 1195 1190 <indexterm> 1196 1191 <primary>contrainte</primary> 1197 <secondary> retirer</secondary>1192 <secondary>supprimer</secondary> 1198 1193 </indexterm> 1199 1194 … … 1363 1358 <para> 1364 1359 La commande <command>GRANT</command> est 1365 utilisée pour accorder des privilèges (on dit aussi granter un privilège).1360 utilisée pour accorder des privilèges (on dit aussi « granter un privilège »). 1366 1361 Par exemple, si <literal>joe</literal> 1367 1362 est un utilisateur et <literal>comptes</literal> une table, le … … 1417 1412 <para> 1418 1413 Un cluster de bases de données <productname>PostgreSQL</productname> 1419 contient une ou plusieurs base s nommées. Si les utilisateurs et groupes1414 contient une ou plusieurs base(s) nommée(s). Si les utilisateurs et groupes 1420 1415 d'utilisateurs sont partagés sur l'ensemble du cluster, aucune 1421 autre donnée n'est partagée. Une connexion cliente1422 donnée sur leserveur ne peut accéder qu'aux données d'une seule base, celle1416 autre donnée n'est partagée. Toute connexion cliente 1417 au serveur ne peut accéder qu'aux données d'une seule base, celle 1423 1418 indiquée dans la requête de connexion. 1424 1419 </para> … … 1434 1429 </note> 1435 1430 1436 <para> 1437 Une base de données contient un ou plusieurs <firstterm>schémas</firstterm> 1438 nommés qui, eux, contiennent des tables. Les schémas contiennent aussi d'autres 1431 <!-- Je ne sais pas si coller le (s) à la suite de la balise fermante passe... 1432 --> 1433 <para> 1434 Une base de données contient un ou plusieurs 1435 <firstterm>schéma</firstterm>(s) nommé(s) qui, eux, contiennent des 1436 tables. Les schémas contiennent aussi d'autres 1439 1437 types d'objets nommés (types de données, fonctions et opérateurs, par 1440 1438 exemple). … … 1454 1452 <listitem> 1455 1453 <para> 1456 pourautoriser de nombreux utilisateurs à utiliser une base de données1457 sans interfére nces entre eux ;1454 autoriser de nombreux utilisateurs à utiliser une base de données 1455 sans interférer avec les autres ; 1458 1456 </para> 1459 1457 </listitem> … … 1461 1459 <listitem> 1462 1460 <para> 1463 pourorganiser les objets de la base de données en groupes logiques afin de faciliter1461 organiser les objets de la base de données en groupes logiques afin de faciliter 1464 1462 leur gestion ; 1465 1463 </para> … … 1503 1501 1504 1502 <para> 1505 Pour créer ou accéder aux objets d'un schéma, on écrit un1503 Pour créer les objets d'un schéma ou y accéder, on écrit un 1506 1504 <firstterm>nom qualifié</firstterm> constitué du nom du schéma et 1507 1505 du nom de la table séparés par un point : 1508 1506 <synopsis><replaceable>schema</replaceable><literal>.</literal><replaceable>table</replaceable></synopsis> 1509 Cela fonctionne partout où un nom de table est attendu, ce qui inclu eles1507 Cela fonctionne partout où un nom de table est attendu, ce qui inclut les 1510 1508 commandes de modification de la table et les commandes d'accès aux données 1511 1509 discutées dans les chapitres suivants. (Pour des raisons de 1512 simplification, il n'est question que de tables, mais les mêmes principes1513 s'appliquent à d'autres types d'objets nommés, comme les types et les1510 simplification, seules les tables sont évoquées, mais les mêmes principes 1511 s'appliquent aux autres objets nommés, comme les types et les 1514 1512 fonctions.) 1515 1513 </para> 1516 1514 1517 1515 <para> 1518 En fait, la syntaxe encore plus générale1516 La syntaxe encore plus générale 1519 1517 <synopsis><replaceable>base</replaceable><literal>.</literal><replaceable>schema</replaceable><literal>.</literal><replaceable>table</replaceable></synopsis> 1520 1518 peut aussi être utilisée, mais à l'heure actuelle, cette syntaxe n'existe … … 1607 1605 liste de schémas dans lesquels chercher. La première table correspondante 1608 1606 est considérée comme la table voulue. S'il n'y a pas de correspondance, une 1609 erreur est remontée, même si des noms de table correspondant existent dans1610 d'autres schémas de la base.1607 erreur est remontée, quand bien même il existerait des tables dont le nom 1608 correspond dans d'autres schémas de la base. 1611 1609 </para> 1612 1610 … … 1640 1638 1641 1639 <para> 1642 C'est, par défaut, dans le premier schéma du chemin de recherche qui existe que sont1643 créés les nouveaux objets. C'est la raison1640 C'est, par défaut, dans le premier schéma du chemin de recherche qui 1641 existe que sont créés les nouveaux objets. C'est la raison 1644 1642 pour laquelle les objets sont créés, par défaut, dans le schéma public. 1645 1643 Lorsqu'il est fait référence à un objet, dans tout autre contexte, sans … … 1654 1652 <programlisting>SET search_path TO mon_schema,public;</programlisting> 1655 1653 (<literal>$user</literal> est omis à ce niveau car il n'est pas 1656 immédiatement nécessaire.) Il est alors possible d' à la table sans1657 qualificationpar un schéma :1654 immédiatement nécessaire.) Il est alors possible d'accéder à la table 1655 sans qu'elle soit qualifiée par un schéma : 1658 1656 <programlisting>DROP TABLE ma_table;</programlisting> 1659 1657 Puisque <literal>mon_schema</literal> est le premier élément du … … 1678 1676 Le chemin de recherche fonctionne de la même façon pour les noms de type de 1679 1677 données, les noms de fonction et les noms d'opérateur que pour les noms de 1680 table s. Les noms des types de données et des fonctions peuvent être qualifiés de la1678 table. Les noms des types de données et des fonctions peuvent être qualifiés de la 1681 1679 même façon que les noms de table. S'il est nécessaire d'écrire un nom 1682 1680 d'opérateur qualifié dans une expression, il y a une condition 1683 1681 spéciale. Il faut écrire : 1684 1682 <synopsis><literal>OPERATOR(</literal><replaceable>schéma</replaceable><literal>.</literal><replaceable>opérateur</replaceable><literal>)</literal></synopsis> 1685 Cela afin d'éviter toute ambiguïté syntaxique. En voici un 1686 exemple 1683 Cela afin d'éviter toute ambiguïté syntaxique. Par exemple : 1687 1684 <programlisting>SELECT 3 OPERATOR(pg_catalog.+) 4;</programlisting> 1688 1685 En pratique, il est préférable de s'en remettre au chemin de recherche pour les opérateurs, … … 1704 1701 propriétaire du schéma doit granter le droit <literal>USAGE</literal> sur 1705 1702 le schéma. Pour autoriser les utilisateurs à manipuler les objets d'un 1706 schéma, des privilèges supplémentaires doivent peut-êtreêtre accordés, en1703 schéma, des privilèges supplémentaires doivent éventuellement être accordés, en 1707 1704 fonction de l'objet. 1708 1705 </para> 1709 1706 1710 1707 <para> 1711 Un utilisateur peut aussi être autorisé à créer des objets dans 1712 schéma d e quelqu'un d'autre. Pour cela, le privilège1708 Un utilisateur peut aussi être autorisé à créer des objets dans le 1709 schéma d'un d'autre. Pour cela, le privilège 1713 1710 <literal>CREATE</literal> sur le schéma doit être accordé. Par défaut, 1714 1711 tout le monde bénéficie des droits <literal>CREATE</literal> et … … 1777 1774 ont implicitement accès au schéma public. Cela permet de simuler une 1778 1775 situation dans laquelle les schémas ne sont pas disponibles. 1779 Cette situation est essentiellement recommandée pour les utilisateurs1780 seuls ou quelques d'utilisateurs concurents au sein d'une base de1781 données. Cette configuration permet aussi une transition1782 en douceur depuis un monde où les schémas sont inconnus ;1776 Cette situation est essentiellement recommandée lorsqu'il n'y a qu'un 1777 utilisateur, ou un très petit nombre d'utilisateurs qui coopèrent au 1778 sein d'une base de données. Cette configuration permet aussi d'opérer 1779 une transition en douceur depuis un monde où les schémas sont inconnus ; 1783 1780 </para> 1784 1781 </listitem> … … 1786 1783 <listitem> 1787 1784 <para> 1788 un schéma peut être créé pour chaque utilisateur, avec un 1789 nom identique à celui de l'utilisateur. Le 1790 chemin de recherche par défaut commence par 1791 <literal>$user</literal>, ce qui correspond au nom de l'utilisateur. 1792 Si chaque utilisateur dispose d'un schéma distinct, tout utilisateur accède, par 1793 défaut, à son propre schéma. 1785 pour chaque utilisateur, un schéma, de nom identique à celui de 1786 l'utilisateur, peut être créé. Le chemin de recherche par défaut 1787 commence par <literal>$user</literal>, soit le nom de l'utilisateur. 1788 Si tous les utilisateurs disposent d'un schéma distinct, ils accèdent, par 1789 défaut, à leur propre schéma. 1794 1790 <!-- </para> 1795 1791 … … 1797 1793 Dans cette configuration, il est possible de révoquer l'accès 1798 1794 au schéma public (voire de supprimer ce schéma) 1799 pour con traindre les utilisateurs àleur propre schéma ;1795 pour confiner les utilisateurs dans leur propre schéma ; 1800 1796 </para> 1801 1797 </listitem> … … 1809 1805 pour permettre aux autres utilisateurs d'y accéder. Les utilisateurs 1810 1806 peuvent alors se référer à ces objets additionnels en qualifiant 1811 leur s nomsdu nom de schéma ou ajouter les schémas1807 leur nom du nom de schéma ou ajouter les schémas 1812 1808 supplémentaires dans leur chemin de recherche, au choix. 1813 1809 </para> … … 1821 1817 1822 1818 <para> 1823 Dans le standard SQL, la notion d'objets d umême schéma1819 Dans le standard SQL, la notion d'objets d'un même schéma 1824 1820 appartenant à des utilisateurs différents n'existe pas. De plus, 1825 1821 certaines implantations ne permettent pas de créer des 1826 schémas qui ont unnom différent de celui de leur propriétaire.1822 schémas de nom différent de celui de leur propriétaire. 1827 1823 En fait, les concepts de schéma et d'utilisateur sont presque 1828 1824 équivalents dans un système de base de données qui n'implante … … 1847 1843 <foreignphrase>namespace</foreignphrase> en 1848 1844 autorisant (peut-être de façon limitée) l'accès inter-bases 1849 de données. Dans ce cas, la portabilité maximale seraobtenue en n'utilisant1845 de données. Dans ce cas, la portabilité maximale est obtenue en n'utilisant 1850 1846 pas les schémas. 1851 1847 </para> … … 1879 1875 sont pas des capitales. Mais, que se passe-t'il dans le cas où toutes 1880 1876 les données d'une ville doivent être récupérées, qu'elle soit une capitale 1881 ou non ? 1882 L'héritage peut aider à résoudre ce problème. La 1877 ou non ? L'héritage peut aider à résoudre ce problème. La 1883 1878 table <structname>capitales</structname> est définie pour hériter de 1884 1879 <structname>villes</structname> : … … 1902 1897 <para> 1903 1898 Dans <productname>PostgreSQL</productname>, une table peut hériter de zéro 1904 à plusieurs autres tables et une requête faire référence à toutes1905 l es lignes d'une table ou à toutes les lignes d'une table plus celles1899 à plusieurs autres tables et une requête faire référence aux 1900 lignes d'une table ou à celles d'une table et de ses 1906 1901 des descendantes. Ce dernier comportement est celui par défaut. 1907 1902 </para> 1908 1903 <para> 1909 Par 1910 exemple, la requête suivante retourne les noms et altitudes de toutes les villes, y compris1911 les capitales, situées à une altitude supérieureà 500 pieds :1904 Par exemple, la requête suivante retourne les noms et altitudes de toutes 1905 les villes, y compris les capitales, situées à une altitude supérieure 1906 à 500 pieds : 1912 1907 1913 1908 <programlisting>SELECT nom, altitude … … 1915 1910 WHERE altitude > 500;</programlisting> 1916 1911 1917 Étant donnéles données du tutoriel de <productname>PostgreSQL</productname>1912 Avec les données du tutoriel de <productname>PostgreSQL</productname> 1918 1913 (voir <xref linkend="tutorial-sql-intro"/>), ceci renvoie : 1919 1914 … … 1952 1947 1953 1948 <para> 1954 Dans certain cas, il peut être intéressant de savoir de quelle table provient une ligne1949 Dans certains cas, il peut être intéressant de savoir de quelle table provient une ligne 1955 1950 donnée. Une colonne système appelée <structfield>TABLEOID</structfield> 1956 1951 présente dans chaque table donne la table d'origine : … … 1968 1963 139798 | Madison | 845</programlisting> 1969 1964 1970 ( La reproduction de cet exemple conduiraprobablement à des1965 (Reproduire cet exemple conduit probablement à des 1971 1966 OID numériques différents). Une jointure avec 1972 1967 <structname>pg_class</structname>, permet d'obtenir les noms réels des tables : … … 1993 1988 <programlisting>INSERT INTO villes (nom, population, altitude, etat) 1994 1989 VALUES ('New York', NULL, NULL, 'NY');</programlisting> 1995 On p eut espérer que les données soient magiquement routées vers la table1996 <structname>capitales</structname> mais ce la n'arrive pas :1990 On pourrait espérer que les données soient magiquement routées vers la table 1991 <structname>capitales</structname> mais ce n'est pas le cas : 1997 1992 <command>INSERT</command> insère toujours dans la table indiquée. Dans 1998 1993 certains cas, il est possible de rediriger l'insertion en utilisant une … … 2013 2008 <para> 2014 2009 Une table peut hériter de plusieurs tables, auquel cas elle possède 2015 l'union des colonnes définies par les tables parents. Toute colonne déclarée2016 dans la définition de la table enfant est ajoutée à ce lles-ci. Si le même nom2017 de colonne apparaît dans plusieurs tables parent, ou à la fois dans une2018 table parentet dans la définition de la table enfant, alors ces colonnes sont2010 l'union des colonnes définies par les tables mèress. Toute colonne déclarée 2011 dans la définition de la table enfant est ajoutée à cette dernière. Si le même nom 2012 de colonne apparaît dans plusieurs tables mères, ou à la fois dans une 2013 table mère et dans la définition de la table enfant, alors ces colonnes sont 2019 2014 <quote>assemblées</quote> pour qu'il n'en existe qu'une dans la table 2020 2015 enfant. Pour être assemblées, les colonnes doivent avoir le même type de … … 2025 2020 2026 2021 <para> 2027 L'héritage de table est typiquement établi lors dela création de la table2028 enfant en utilisantla clause <literal>INHERITS</literal> de l'instruction2022 L'héritage de table est établi à la création de la table 2023 enfant, à l'aide de la clause <literal>INHERITS</literal> de l'instruction 2029 2024 <xref linkend="sql-createtable" endterm="sql-createtable-title"/>. 2030 Alternativement, il est possible d'ajouter à une table déjàdéfinie de façon2031 compatible une nouvelle relation de parenté à l'aide de la clause2025 Alternativement, il est possible d'ajouter à une table, définie de façon 2026 compatible, une nouvelle relation de parenté à l'aide de la clause 2032 2027 <literal>INHERIT</literal> de 2033 2028 <xref linkend="sql-altertable" endterm="sql-altertable-title"/>. Pour cela, … … 2055 2050 <literal>INCLUDING CONSTRAINTS</literal> de <literal>LIKE</literal> doit 2056 2051 être indiquée car le nouvel enfant doit avoir des contraintes qui 2057 correspondent à celles du parent pour être considéré compatible.2058 </para> 2059 2060 <para> 2061 Une table parentne peut pas être supprimée tant qu'elle a des enfants.2052 correspondent à celles du parent pour être considérée compatible. 2053 </para> 2054 2055 <para> 2056 Une table mère ne peut pas être supprimée tant qu'elle a des enfants. 2062 2057 Pas plus que les colonnes de tables enfants ne peuvent être supprimées ou 2063 modifiées si elles sont héritées d'une table parent.2058 modifiées si elles sont héritées. 2064 2059 La suppression d'une table et de tous ces descendants peut être aisément 2065 obtenue en supprimant la table parentavec l'option2060 obtenue en supprimant la table mère avec l'option 2066 2061 <literal>CASCADE</literal>. 2067 2062 </para> … … 2071 2066 propage toute modification dans les définitions des colonnes et 2072 2067 contraintes de vérification à travers la hiérarchie d'héritage. Là encore, 2073 supprimer des colonnes ou des contraintes sur des tables parentes n'est possible2068 supprimer des colonnes ou des contraintes sur des tables mèrees n'est possible 2074 2069 qu'avec l'option <literal>CASCADE</literal>. <command>ALTER TABLE</command> 2075 2070 suit les mêmes règles d'assemblage de colonnes dupliquées et de rejet que … … 2077 2072 </para> 2078 2073 2079 <!-- caveats != hints --> 2074 <!-- caveats != hints 2075 Je parlerai de chausse-trappe --> 2080 2076 <sect2 id="ddl-inherit-caveats"> 2081 2077 <title>Restrictions</title> … … 2092 2088 <para> 2093 2089 Il existe une réelle limitation à la fonctionnalité d'héritage : les index 2094 ( ce qui inclueles contraintes d'unicité) et les contraintes de clés étrangères2095 ne s'appliquent qu'aux tables , pas à leurs héritiers. Cela2096 est v raipour le côté référençant et le côté référencé d'une contrainte2090 (dont les contraintes d'unicité) et les contraintes de clés étrangères 2091 ne s'appliquent qu'aux tables mères, pas à leurs héritiers. Cela 2092 est valable pour le côté référençant et le côté référencé d'une contrainte 2097 2093 de clé étrangère. Ce qui donne, dans les termes de l'exemple ci-dessus : 2098 2094 … … 2105 2101 <structname>capitales</structname> de posséder des lignes 2106 2102 avec des noms dupliqués dans <structname>villes</structname>. Et ces lignes 2107 dupliquées s'affichent par défaut dans les requêtes sur2108 <structname>villes</structname>. En fait, par défaut,2109 <structname>capitales</structname> n'a pas de contrainte2110 d'unicité du tout et, du coup, peut contenir plusieurs lignes avec le2111 même nom. Une contrainte d'unicité peut être ajoutée à2112 <structname>capitales</structname> mais cela n'empêche pas la duplication2113 avec <structname>villes</structname> ;2103 upliquées s'affichent par défaut dans les requêtes sur 2104 <structname>villes</structname>. En fait, par défaut, 2105 <structname>capitales</structname> n'a pas de contrainte 2106 d'unicité du tout et, du coup, peut contenir plusieurs lignes avec le 2107 même nom. Une contrainte d'unicité peut être ajoutée à 2108 <structname>capitales</structname> mais cela n'empêche pas la duplication 2109 avec <structname>villes</structname> ; 2114 2110 </para> 2115 2111 </listitem> … … 2117 2113 <listitem> 2118 2114 <para> 2119 de façon similaire, s 'il faut préciser que2115 de façon similaire, si 2120 2116 <structname>villes</structname>.<structfield>nom</structfield> fait référence 2121 2117 (<literal>REFERENCES</literal>) à une autre table, cette contrainte … … 2130 2126 <listitem> 2131 2127 <para> 2132 l'indication que la colonne d'une autre table <literal>REFERENCES 2133 villes(nom)</literal> autorise l'autre table à contenir les noms des 2134 villes mais pas les noms des capitales. Il n'existe pas de 2135 contournement efficace de ce cas. 2128 si une autre table indique <literal>REFERENCES villes(nom)</literal>, 2129 cela l'autorise à contenir les noms des villes mais pas les noms des 2130 capitales. Il n'existe pas de contournement efficace de ce cas. 2136 2131 </para> 2137 2132 </listitem> … … 2147 2142 <para> 2148 2143 Dans les versions de <productname>PostgreSQL</productname> antérieures à 2149 la7.1, le comportement par défaut consistait à ne pas inclure les tables enfants dans les2144 7.1, le comportement par défaut consistait à ne pas inclure les tables enfants dans les 2150 2145 requêtes. Il s'est avéré que cela était source d'erreur et violait le 2151 2146 standard SQL. Ce comportement peut être retrouvé en désactivant le … … 2157 2152 </sect1> 2158 2153 2159 <!-- ICI -->2160 2154 <sect1 id="ddl-partitioning"> 2161 2155 <title>Partitionnement</title> … … 2200 2194 <para> 2201 2195 lorsque les requêtes ou les mises à jour accèdent à un important pourcentage 2202 d'une unique partition, les performances peuvent être grandement améliorées2196 d'une seule partition, les performances peuvent être grandement améliorées 2203 2197 par l'utilisation avantageuse de parcours séquentiels sur cette 2204 2198 partition plutôt que d'utiliser un index et des lectures aléatoires … … 2256 2250 <listitem> 2257 2251 <para> 2258 La table est partitionnée en <quote>groupes</quote> (ou échelles) définis par une 2252 La table est partitionnée en <quote>intervalles</quote> (ou échelles) 2253 définis par une 2259 2254 colonne clé ou par un ensemble de colonnes, sans recouvrement entre 2260 2255 les échelles de valeurs affectées aux différentes partitions. Il est … … 2374 2369 Soit la base de données d'une grande fabrique de glaces. La compagnie 2375 2370 mesure le pic de température journalier ainsi que les ventes de glaces 2376 dans chaque région. Conceptuellement, la table ressemble à cela :2371 dans chaque région. Conceptuellement, la table ressemble à : 2377 2372 2378 2373 <programlisting>CREATE TABLE mesure ( … … 2432 2427 <listitem> 2433 2428 <para> 2434 Nous devonsfournir des contraintes de table qui interdisent les2429 Il est nécessaire de fournir des contraintes de table qui interdisent les 2435 2430 recouvrements. Plutôt que de simplement créer les tables de la 2436 partition comme ci-dessus, le script de création de tables devrait2437 ressembler à ceci :2431 partition comme ci-dessus, le script de création de tables ressemble 2432 à ; 2438 2433 2439 2434 <programlisting>CREATE TABLE mesure_a2006m02 ( … … 2473 2468 <listitem> 2474 2469 <para> 2475 Nous voulons que notre application soit capable de dire 2476 <literal>INSERT INTO mesure...</literal> et que les données soient 2477 redirigées dans la table de partition appropriée. Nous pouvons 2478 arranger cela en attachant une fonction trigger à la table maître. 2470 L'application doit dire <literal>INSERT INTO mesure...</literal> et les 2471 données être redirigées dans la table de partition appropriée. Pour 2472 cela une fonction déclencheur est attachée à la table maître. 2479 2473 Si les données ne sont ajoutées que dans la dernière partition, 2480 nous pouvons utiliser une fonction triggertrès simple.2474 la fonction est très simple. 2481 2475 2482 2476 <programlisting> … … 2491 2485 </programlisting> 2492 2486 2493 Après avoir créé la fonction, nous pouvons créer un trigger qui 2494 appelle la fonction trigger : 2487 Le déclencheur qui appelle la fonction est créé à sa suite : 2495 2488 2496 2489 <programlisting> … … 2500 2493 </programlisting> 2501 2494 2502 Nous devons redéfinir la fonction trigger chaque mois pour qu'il2503 pointe toujours sur partition en cours. Par contre, la définition du2504 trigger n'a pas besoin d'être mise à jour.2495 La fonction déclencheur doit être redéfinie chaque mois pour qu'elle 2496 pointe toujours sur la partition active. La définition du déclencheur 2497 n'a pas besoin d'être redéfinie. 2505 2498 </para> 2506 2499 … … 2508 2501 Il est également possible de laisser le serveur localiser la partition 2509 2502 dans laquelle doit être insérée la ligne proposée en entrée. Une 2510 fonction trigger permet d'obtenir ce résultat :2503 fonction déclencheur plus complexe peut être utilisée pour cela : 2511 2504 2512 2505 <programlisting> … … 2530 2523 </programlisting> 2531 2524 2532 La définition du trigger est la même qu'avant. Notez que chaque2525 La définition du déclencheur ne change pas. Chaque 2533 2526 test <literal>IF</literal> doit correspondre exactement à la 2534 contrainte <literal>CHECK</literal> pourcette partition.2535 </para> 2536 2537 <para> 2538 Bien que cette fonction soit plus complexe que le casdu mois seul,2539 elle n'a pas besoin d'être mise à jour aussi fréquemment car les2540 branches peuvent être ajoutées avant le besoin.2527 contrainte <literal>CHECK</literal> de cette partition. 2528 </para> 2529 2530 <para> 2531 Bien que cette fonction soit plus complexe que celle du mois seul, 2532 il n'est pas nécessaire de l'actualiser aussi fréquemment, les branches 2533 pouvant être ajoutées avant d'être utiles. 2541 2534 </para> 2542 2535 2543 2536 <note> 2544 2537 <para> 2545 En pratique, il pourrait être mieux de vérifier en premier la 2546 dernière partition créée si la plupart des insertions vont dans 2547 cette partition. Pour des raisons de simplicité, nous avons 2548 montré les tests du trigger dans le même ordre que les autres 2549 parties de cet exemple. 2538 En pratique, il pourrait préférable de vérifier prioritairement la 2539 dernière partition créée si la plupart des insertions lui sont 2540 destinées. Pour des raisons de simplicité, les tests du déclencheur 2541 sont présentés dans le même ordre que les autres parties de l'exemple. 2550 2542 </para> 2551 2543 </note> … … 2572 2564 d'en ajouter périodiquement de nouvelles pour de nouvelles données. 2573 2565 Un des principaux avantages du partitionnement est précisément qu'il 2574 autorise une exécution quasi-instantanée de cette tâche, autrementbien2575 plus difficile , en permettant la manipulation de la structure de la2566 autorise une exécution quasi-instantanée de cette tâche, bien 2567 plus difficile autrement, en permettant la manipulation de la structure de la 2576 2568 partition, plutôt que de déplacer physiquement de grands volumes de données. 2577 2569 </para> … … 2595 2587 pour sauvegarder les données en utilisant <command>COPY</command>, 2596 2588 <application>pg_dump</application> ou tout autres outil. C'est aussi le 2597 moment d'agréger des données en des formats plus petits, de réaliser d'autres2589 moment d'agréger des données en des formats plus denses, de réaliser d'autres 2598 2590 opérations sur les données ou de créer des rapports. 2599 2591 </para> … … 2715 2707 <para> 2716 2708 Une approche différente pour la redirection des insertions dans la 2717 table fille appropriée est de configurer des règles, au lieud'un2718 trigger, sur la table maître. Par exemple :2709 table fille appropriée est de configurer des règles, à la place d'un 2710 déclencheur, sur la table maître. Par exemple : 2719 2711 2720 2712 <programlisting> … … 2725 2717 INSERT INTO mesure_a2006m02 VALUES (NEW.*); 2726 2718 ... 2727 CREATE RULE mesure_insert_ y2008m01 AS2719 CREATE RULE mesure_insert_a2008m01 AS 2728 2720 ON INSERT TO mesure WHERE 2729 2721 ( date_trace >= DATE '2008-01-01' AND date_trace < DATE '2008-02-01' ) … … 2732 2724 </programlisting> 2733 2725 2734 Une règle est plus coûteuse qu'un trigger mais ce coût est payé une fois2735 par requête au lieu d'une fois par ligne, donc cette méthode peut être2736 avantageuse pourde grosses insertions. Néanmoins, dans la majorité des2726 Une règle est plus coûteuse qu'un déclencheur mais ce coût est payé une fois 2727 par requête au lieu d'une fois par ligne, cette méthode peut donc s'avérer 2728 avantageuse lors de grosses insertions. Néanmoins, dans la majorité des 2737 2729 cas, la méthode du trigger offre de meilleures performances. 2738 2730 </para> 2739 2731 2740 2732 <para> 2741 Faites attention au fait que les règles ignorent la commande 2742 <command>COPY</command>. Si vous voulez utiliser 2743 <command>COPY</command> pour insérer des données, vous aurez besoin 2744 d'exécuter cette requête dans la bonne table fille plutôt que dans 2745 la table maître. <command>COPY</command> exécute les triggers, donc 2746 vous pouvez les utiliser normalement si vous passez par l'approche 2747 proposée par les triggers. 2733 La commande <command>COPY</command> ignore les règles. Si 2734 <command>COPY</command> est utilisé pour insérer des données, 2735 la copie doit être effectuée sur la partition adéquate plutôt que dans 2736 la table maître. <command>COPY</command> active les déclencheurs. Elle 2737 peut donc être utilisée normalement lorsque cette approche est choisie. 2748 2738 </para> 2749 2739 2750 2740 <para> 2751 2741 Un autre inconvénient de la méthode des règles est qu'il n'existe pas 2752 de moyens simples pourforcer une erreur si l'ensemble des règles2753 ne couvre pas la date d'insertion. La donnée ira silencieusement dans2754 la table maître.2742 de moyens simples de forcer une erreur si l'ensemble des règles 2743 ne couvre pas la date d'insertion. La donnée est alors silencieusement 2744 insérée dans la table maître. 2755 2745 </para> 2756 2746 2757 2747 <para> 2758 Partitioning can also be arranged using a <literal>UNION ALL</literal> 2759 view, instead of table inheritance. For example, 2748 Le partitionnement peut aussi être arrangé à l'aide d'une vue 2749 <literal>UNION ALL</literal>, en lieu et place de l'héritage. Par 2750 exemple : 2760 2751 2761 2752 <programlisting> … … 2769 2760 </programlisting> 2770 2761 2771 Néanmoins, le besoin de créer de nouveaula vue ajoute une étape2762 Néanmoins, le besoin de recréer la vue ajoute une étape 2772 2763 supplémentaire à l'ajout et à la suppression de partitions individuelles 2773 2764 de l'ensemble des données. En pratique, cette méthode a peu d'intérêt 2774 par rapport àl'héritage.2765 au regard de l'héritage. 2775 2766 </para> 2776 2767 … … 2787 2778 il n'existe pas de moyen automatique de vérifier que toutes les 2788 2779 contraintes de vérification (<literal>CHECK</literal>) sont mutuellement 2789 exclusives. Il est plus sûr de créer un code qui génère les2780 exclusives. Il est plus sûr de créer un code qui fabrique les 2790 2781 partitions et crée et/ou modifie les objets associés plutôt que de les 2791 créer chacunmanuellement ;2782 créer manuellement ; 2792 2783 </para> 2793 2784 </listitem> … … 2795 2786 <listitem> 2796 2787 <para> 2797 Les schémas montrés ici supposent que les colonnes clés du2788 les schémas montrés ici supposent que les colonnes clés du 2798 2789 partitionnement d'une ligne ne changent jamais ou, tout du moins, ne 2799 2790 changent pas suffisamment pour nécessiter un déplacement vers une 2800 2791 autre partition. Une commande <command>UPDATE</command> qui 2801 tente de le faire échoue raà cause des contraintes2802 <literal>CHECK</literal>. Si vous avez besoin degérer ce type de cas,2803 vous pouvez placer des triggers convenables pour la mise à jour sur2792 tente de le faire échoue à cause des contraintes 2793 <literal>CHECK</literal>. Pour gérer ce type de cas, 2794 des déclencheurs peuvent être convenablement positionnés pour la mise à jour sur 2804 2795 les tables de partition mais cela rend la gestion de la structure 2805 2796 beaucoup plus complexe. … … 2809 2800 <listitem> 2810 2801 <para> 2811 Si vous utilisez manuellement<command>VACUUM</command> ou2812 <command>ANALYZE</command> , n'oubliez pas de les utiliser sur chaque2813 partition. Une commande comme :2802 si <command>VACUUM</command> ou 2803 <command>ANALYZE</command> sont lancés manuellement, il est obligatoire 2804 de les utiliser sur chaque partition. Une commande comme : 2814 2805 <programlisting> 2815 2806 ANALYZE mesure; 2816 2807 </programlisting> 2817 ne traite raque la table maître.2808 ne traite que la table maître. 2818 2809 </para> 2819 2810 </listitem> … … 2838 2829 <listitem> 2839 2830 <para> 2840 faites en sorte que les contraintes du partitionnement restent simples. 2841 Dans le cas contraire, le planificateur peut avoir des difficultés à 2842 s'assurer que certaines partitions n'ont pas besoin d'être parcourues. 2843 Utilisez des conditions simples d'égalité pour le partitionnement de 2844 liste ou des tests d'échelle simple, comme illustré dans les exemples 2845 précédents. Une bonne règle est que les contraintes de partitionnement 2846 doivent seulement contenir des comparaisons entre les colonnes de 2847 partitionnement et des constantes en utilisant des opérateurs 2831 les contraintes de partitionnement doivent rester simples. 2832 Dans le cas contraire, le planificateur peut rencontrer des difficultés à 2833 déterminer les partitions qu'il n'est pas nécessaire de parcourir. 2834 Des conditions simples d'égalité pour le partitionnement de 2835 liste ou des tests d'échelle simples lors de partitionnement d'échelle 2836 sont recommandées, comme cela est illustré dans les exemples 2837 précédents. Une bonne règle consiste à s'assurer que les comparaisons 2838 entre colonnes de partitionnement et constantes utilisées par les 2839 contraintes de partitionnement se fassent uniquement à l'aide d'opérateurs 2848 2840 utilisables par les index B-tree. 2849 2841 </para> … … 2854 2846 toutes les contraintes de toutes les partitions de la table maître sont 2855 2847 examinées lors de l'exclusion de contraintes. De ce fait, un grand nombre 2856 de partitions a tendance à augmenterconsidérablement le temps de2857 planification de la requête. Partitionner en utilisantces2858 techniques fonctionne ra bien avec moins de centpartitions ;2859 n'essayez pas d'utiliser plusieurs milliers de partitions.2848 de partitions augmente considérablement le temps de 2849 planification de la requête. Un partitionnement qui utilise ces 2850 techniques fonctionne assez bien jusqu'environ une centaine de partitions ; 2851 il est impensable de vouloir atteindre des milliers de partitions. 2860 2852 </para> 2861 2853 </listitem> … … 2925 2917 2926 2918 <para> 2927 Lorsque des structures de base complexes sont créé s qui impliquent2919 Lorsque des structures de base complexes sont créées qui impliquent 2928 2920 beaucoup de tables avec des contraintes de clés étrangères, des 2929 2921 vues, des déclencheurs, des fonctions, etc., un réseau de dépendances entre … … 2962 2954 lancer 2963 2955 <screen>DROP TABLE produits CASCADE;</screen> 2964 et tous les objets dépendants s eront ainsi effacés. Dans ce cas, cela n'efface pas2965 la table des commandesmais seulement la contrainte de clé étrangère.2966 ( pour vérifier ce que <command>DROP ... CASCADE</command> fait,2956 et tous les objets dépendants sont ainsi effacés. Dans ce cas, la table des 2957 commandes n'est pas supprimée, mais seulement la contrainte de clé étrangère. 2958 (Pour vérifier ce que fait <command>DROP ... CASCADE</command>, on peut 2967 2959 lancer <command>DROP</command> sans <literal>CASCADE</literal> et lire les messages 2968 <literal>NOTICE</literal> ).2960 <literal>NOTICE</literal>.) 2969 2961 </para> 2970 2962 … … 2994 2986 Les dépendances de contraintes de clés étrangères et de colonnes 2995 2987 <foreignphrase>serial</foreignphrase> des versions de <productname>PostgreSQL</productname> 2996 antérieures à 7.3 nesont <emphasis>pas</emphasis> maintenues ou2988 antérieures à 7.3 <emphasis>ne</emphasis> sont <emphasis>pas</emphasis> maintenues ou 2997 2989 créées pendant le processus de mise à jour. Tout autre type de 2998 2990 dépendance est proprement créé pendant une mise à jour à partir d'une traduc/trunk/postgresql/docguide.xml
r973 r1092 4 4 par $Author$ 5 5 révision $Revision$ --> 6 <!-- SAS 20070511, PG624 -->7 6 8 7 <appendix id="docguide"> … … 78 77 documentation FreeBSD</ulink> utilise également DocBook et fournit 79 78 également de bonnes informations, incluant un certain nombre de 80 lignes directrices qu'il peut être bon de prendre en 81 considération. 79 lignes directrices qu'il peut être bon de prendre en considération. 82 80 </para> 83 81 </sect1> … …

