Découvrir PostgreSQL

Découvrir les options de création de table

Testez gratuitement nos 1257 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Vous allez explorer les options avancées de la création de table. Exploitez notamment l'héritage à partir d'une table mère.
08:33

Transcription

J'ai repris le code de création de ma " table ", dans " test ", pour voir deux ou trois choses supplémentaires qui sont intéressantes dans PostgreSQL à connaître sur la création des " tables ". D'abord, je viens de recréer ma " table ", " test.contact. " Et si j'essaye encore, on va me faire, bien entendu, une erreur. La " relation contact " existe déjà dans ce schéma, c'est évident. Vous pouvez utiliser, lorsque vous créez la " table ", juste après " TABLE ", l'instruction " IF NOT EXISTS ". Vous avez compris le sens. Je n'ai plus d'erreur mais simplement une notice, une remarque qui dit, on laisse tomber, ça existe déjà. Vous pouvez aussi créer une " table " temporaire avec la même syntaxe. Une " table " temporaire, c'est une " table " qui ne vivra que la durée de votre session. Ici, vous avez une connexion ouverte à PostgreSQL. Si vous créez une " table " temporaire, elle survivra jusqu'au moment où vous vous déconnectez. Donc, je vais faire un " CREATE TABLE ", et avant " TABLE ", je vais dire " CREATE TEMPORARY ", ou plus court, " TEMP TABLE ". À ce moment-là, vous ne mettez pas le schéma. Vous allez voir. On ne peut pas créer une " relation temporaire " dans un schéma non " temporaire ". Ça veut dire que les " tables temporaires " ont leur propre schéma et donc, elles vont se créer dans ce schéma, spécifiquement, vous n'indiquez pas de schéma. Et voilà votre " table " temporaire. Pour référencer dans votre " SELECT ", la " table " temporaire, vous faites simplement un " SELECT ", sans indiquer de schéma. Et la requête se fera dans la " table temporaire ", on fait " F5 ". Il y a un schéma qui est créé et qui s'appelle pg_temp, quelque chose avec un numéro, dans lequel vous pourriez trouver votre " table " temporaire, mais ce n'est pas nécessaire pour faire votre " SELECT ". Donc, je commente, vous voyez qu'une instruction de commentaire, comme dans tous les dialectes SQL, c'est un double tiret qui va commenter tout ce qui suit dans la ligne. Ça c'est une parenthèse. Je peux créer également une " table " qu'on va appeler " UNLOGGED ", c'est-à-dire non loggée. Je vais l'appeler " contact2 ". Qu'est-ce que c'est qu'une " table " non loggée ? C'est une " table " qui n'est pas durable totalement. Un peu de contexte, dans tous les moteurs de bases de données relationnelles, qui respectent les critères " d'ACIDité " de la transaction, toute écriture doit être atomique, cohérente, isolée et durable. Toute écriture transactionnelle s'entend. Une transaction doit avoir ces quatre propriétés. On va se concentrer sur la dernière propriété, qui est la propriété durable, qui veut dire que lorsque j'ai fait une écriture, et lorsqu'on fait un commit de la transaction, on va revenir dans un instant sur ce concept, il faut que l'écriture soit réellement faite sur le disque. Pour des raisons de performance, les écritures ne sont pas écrites directement dans les données elles-mêmes, mais dans un journal de transaction, ce que nous avons vu au début. On en a parlé, ce qu'on appelle un " WAL ", ou un " Write Ahead Log ". Un journal d'écriture en avance. C'est quelque chose qui va permettre d'optimiser les performances, d'écriture sur le disque et de gérer des situations transactionnelles. Donc, lorsque vous faites une écriture dans cette " table ", ou plutôt, on va dire dans cette " table ", qui n'est pas " UNLOGGED ". Chaque fois vous écrivez des données, vous allez écrire dans le journal de transactions, de la base de données " pacha ". Par contre, si vous dites ici pour " contact2 " que la " table " est " UNLOGGED ", vous exprimez le fait que les écritures ne vont pas être inscrites dans le journal de transactions. Et elles vont être inscrites plus tard, dans le fichier de données. Ça veut dire qu'au moment de l'écriture, ça va rester sur le serveur, dans la mémoire vive. Si la machine crashe, votre " table contact2 " ne sera peut-être pas à jour avec la situation transactionnelle, dans laquelle vous avez laissé la base de données, lorsque le système a crashé. Vous avez de meilleures performances d'ecriture sur cette " table ", parce qu'il y a beaucoup moins d'écriture sur le disque, lorsque vous faites des insertions. Par contre, vous n'avez pas de garantie de durabilité de vos transactions. On pourrait considérer comme ça une forme de " table " temporaire, mais persistante. La structure va persister. Le contenu, on ne peut pas vraiment lui faire confiance, dans toutes les situations, surtout lorsqu'il y a un crash du système. Et dans les faits, lorsqu'il y a un crash du système, les " tables " qui sont marquées " UNLOGGED " sont totalement vidées par PostgreSQL, lorsqu'il redémarre. Ça veut dire que vous allez plutôt les utiliser comme des " tables " à la structure persistante, mais aux données temporaires. Enfin, vous avez un mécanisme d'héritage entre les " tables ". Je vous montre ça maintenant. On enlève tout ça et on va faire une " table " qu'on va appeler " contact3 ". Et on va lui dire qu'elle a non pas tout ça, mais un " email ". On va faire un " varchar(100) ", un peu plus grand. On va dire " not null ", c'est pas grave. Et donc, cette " table " maintenant, on va dire, après les parenthèses, qu'elle hérite d'une autre " table ". Comme ceci, " INHERITS ", et je vais dire " test.contact ". Ça veut dire que cette " table " va hériter d'un certain nombre de propriétés, le stockage et les colonnes d'une, ou même d'ailleurs de plusieurs " tables ". On peut faire un héritage multiple, ça devient un peu compliqué. Mais on va rester sur un seul héritage, et si je fais ça, et il ne faut que j'oublie les parenthèses, si je fais ça, on va regarder de quoi il s'agit maintenant. Je suis dans " test ", je rafraîchis, j'ai une table qui s'appelle " contact3 ", On s'en souvient, c'est bien celle-là, et elle va contenir quatre " colonnes ", " contactid, nom, prénom et email. " Intéressant, non ? Alors, regardez une chose par rapport à l'héritage, ce que je vais faire maintenant, c'est un " ALTER TABLE test.contact ". Je vais faire un " ADD ", pour rajouter une colonne que je vais appeler " adresse ", j'invente, " varchar(50). " Je vais dire qu'elle peut avoir un " NULL ". Je sélectionne et j'exécute. Je l'ai fait deux fois, c'est pas grave. J'ai ici donc " contact ", je rafraîchis. J'ai bien une " adresse ". Et qu'est-ce que j'ai dans " contact3 ", à votre avis ? Il faut que je rafraîchisse un peu. " L'adresse " également. Il y a vraiment une relation d'héritage, c'est-à-dire qu'il y a un lien maintenant fort entre le parent et la " table " héritée. Vous avez une deuxième option, vous pouvez dire, " LIKE " au lieu de " INHERITS ", et à ce moment-là, au lieu de le mettre ici, vous le mettez ici, sans parenthèses, c'est un peu compliqué en effet. Je vais faire un " contact4 ", j'enlève ça. Donc, j'ai un " contact4 ", on va y aller, qui comporte toutes mes " colonnes ", parce que j'ai dit " l'email ", mais ensuite " LIKE test.contact ", donc j'ai repris le contenu de " test.contact ". Et donc, j'ai toutes mes " colonnes ", mais maintenant, je n'ai plus de lien entre les deux, c'est la différence. Si j'utilise INHERITS, je peux faire des modifications dans " contact ", et elles seront appliquées dans " contact3 ". Par contre ici, j'ai juste repris la structure, que j'ai trouvée dans " contact ", vous voyez ici, on me dit c'est " hérité " de. C'était en une seule fois pour " contact4 ". Vous voyez que simplement, le schéma ici est différent de celui-ci. Ici, on me dit on " hérite ", mais ici on me dit, on a repris en une seule fois les " colonnes ", et il n'y a plus de lien entre " contact " et " contact4 ".

Découvrir PostgreSQL

Comprenez le fonctionnement de PostgreSQL ainsi que son architecture. Effectuez les tâches courantes de sécurité, de création de bases de données et d'objets, etc.

2h46 (30 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
PostgreSQL PostgreSQL 9
Spécial abonnés
Date de parution :31 mars 2016

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !