Page suivante Page précédente Table des matières 4. Évaluation de postgreSQL pour un environnement de production Par Jurgen Defurne 4.1 Introduction Avec l'arrivée de logiciels relativement puissants, libres et/ou bon marché, je voulais voir si je serais capable de créer un environnement de production autour de Linux et d'un SGBD. Dans le passé j'avais travaillé avec plusieurs produits de SGBD dans plusieurs environnements. Mon but était d'évaluer l'ensemble Linux/postgreSQL comparé aux plusieurs environnements qui m'étaient familiers. Je vais extraire de ces environnements les aspects que je pense importants dans un environnement de production. 4.2 Environnements de production passés J'ai travaillé à trois niveaux d'environnements de production. C'étaient l'environnement PC sans connexion, l'environnement PC connecté (réseau avec serveur de fichiers/d'imprimantes), et environnement multi-utilisateurs multi-tâches (mini-ordinateur). J'introduirai les outils dans cet ordre de complexité. Quelques termes auront besoin d'une définition explicite, parce que la terminologie xBase est quelquefois trompeuse. Le terme "base de données" ici signifie la collection de plusieurs tables en relation nécessaire pour enregistrer des données organisées. Le terme "table" est utilisé pour désigner une collection de données identiques; un ensemble. Je donne ces précisions car dans la terminologie originale xBase, "base de donnée" était utilisé pour signifier "table". FoxBase Tout en étant effectivement un clone beaucoup plus rapide de dBase III, FoxBase contenait le minimum nécessaire pour définir les tables et les bases de données ainsi qu'un langage qui contenait tout le nécessaire pour écrire très rapidement des applications. Une base de données consistait en plusieurs tables et leurs index. L'association des tables et de leurs index devait être faite explicitement avec des commandes. Le langage de programmation utilisé est complètement procédural. Il contient des déclarations pour créer des menus, ouvrir et fermer des tables, filtrer des tables (interroger), insérer, mettre à jour et supprimer des enregistrements, voir des enregistrements à travers des mises en page et une commande de parcours. Définir toutes ces choses dans un programme est tout à fait évident. Les enregistrements sont manipulés comme des variables de programme. Toutes les données sont enregistrées au format ASCII. Les "macros", héritées de dBase, constituaient une particularité. Ces macros sont des chaînes de texte, qui pouvaient être compilées et interprétées à l'exécution. C'était une particularité nécessaire, vu que la plupart des commandes prenaient des arguments chaînes sans guillemets, P. ex. OPEN MY_TABLE. Si on voulait définir une commande avec un argument, on ne pouvait pas directement se référer à une variable. Si on essayait d'exécuter OPEN ARG_TABLE, le programme chercherait le fichier "ARG_TABLE". Pour pallier ce problème on a besoin de coder comme suit : ARG_TABLE = "MY_TABLE" OPEN &ARG_TABLE Clipper Clipper a commencé comme compilateur dBase, mais s'est étoffé bientôt d'extensions puissantes au langage. J'ai aussi travaillé avec les versions été 87 et 5.0. Au niveau de la base de données, ça ne changeait pas beaucoup de FoxBase, mais aux niveaux interface et programmation, plusieurs caractéristiques avancées offraient des temps de cycle de développement plus rapides et une interface utilisateur avancée. La caractéristique macro était encore disponible, mais Clipper l'étendait à l'aide de blocs de code. Dans l'implémentation originale, une macro avait besoin d'être évaluée à chaque fois qu'elle était utilisée. Dans le cas où des macros étaient utilisées pour filtrer des données, il en résultait un gaspillage de temps machine. L'introduction des blocs de code a permis de compiler une macro juste une fois puis d'utiliser la version compilée. D'autres caractéristiques étaient l'introduction de quelques classes orientées objet pour l'interface utilisateur, un type de tableau multidimensionnel puissant, des déclarations de variables statiques et locales et une pléthore de fonctions pour manipuler des tableaux et des tables. Le revers de tout ceci était qu'apprendre à utiliser effectivement le langage prenait un peu plus de temps. J'avais deux livre sur Clipper 5.0 et ils sont assez gros. FoxPro 2.0 FoxPro fut le successeur de FoxBase. Il ajoutait des caractéristiques d'interface graphique à l'interface texte, rendant possible le travail avec des fenêtres qui se recouvrent. FoxPro 2.0 a aussi ajouté des commandes SQL intégrées. C'était seulement un sous-ensemble avec SELECT, INSERT, UPDATE et DELETE, mais ça offrait déjà un avantage substantiel par rapport aux requêtes standard. Il offrait aussi une meilleure intégration entre les tables et leurs index, et un des optimiseurs de requêtes les plus puissants jamais développés. Il offrait aussi quelques outils de développement, dont le plus important était le développement d'écrans et les outils de documentation du programme source. Clipper et FoxPro ont aussi rendu possible de programmer pour des réseaux et donc permis les systèmes de bases de données multi-utilisateurs. WANG PACE WANG PACE est un système de développement SGBD totalement intégré qui tourne sur les mini-ordinateurs WANG VS. Il offre un dictionnaire étendu de données avec validations au niveau du champ et au niveau de l'enregistrement, des triggers de langage de haut niveau, des définitions de vues. Tous les objets définis contiennent un compteur de version. Quand un objet est modifié et que les programmes suivants ne le sont pas, alors une erreur d'exécution est générée quand les versions compilées ne correspondent pas aux versions DD. Il offre aussi un éditeur d'écran puissant, un éditeur de rapport et un système de requête par l'exemple. L'accès au moyen de COBOL, COBOL85 ou RPGII est disponible avec un préprocesseur qui compile les commandes intégrées en appels de l'API. 4.3 Résumé des caractéristiques importantes Si je regarde rétrospectivement ces systèmes, quelles étaient les caractéristiques importantes qui rendaient la programmation plus productive ? Il faut le voir en référence à postgreSQL et aux librairies disponibles pour l'interfacer. Il faut aussi les voir du point de vue du programmeur de production, qui doit pouvoir écrire des applications sans être ennuyé par des détails futiles. Traduction de noms de fichiers vers des noms de variables natives. Le fait de définir un nom de champ pour une table le rend disponible sous le même nom au programme qui peut alors l'utiliser comme une variable native ordinaire. Système d'allocation de mémoire uniforme. Les systèmes xBase ont un schéma d'allocation de mémoire dynamique, qui est complètement pris en charge par la librairie runtime. COBOL est alloué statiquement en totalité. Dans aucun de ces langages le programmeur n'a à s'inquiéter de suivre la mémoire non allouée. Mise à jour directe par l'enregistrement courant. L'enregistrement manipulé est disponible pour mettre à jour la table à l'aide d'un commande UPDATE quelconque. Les commandes de base de donnée ont le même format que le langage d'application Quand on programme en xBase, les commandes pour extraire et manipuler les données des tables de la base sont partie intégrante du langage de procédures. En COBOL, les commandes étaient intégrées et prises en charge par un préprocesseur. La syntaxe des commandes disponibles était faite pour ressembler à la syntaxe COBOL, avec ses points forts et ses point faibles. Définition et utilisation d'écrans simplifiées. En xBase, il y a des commandes puissantes mais simples pour définir des écrans. Les écrans sont invoqués à l'aide seulement d'une ou deux commandes. Dans WANG PACE, les écrans ne peuvent être définis que par l'éditeur d'écrans. Il y a trois commandes disponibles : une pour utiliser des menus, une pour traiter un enregistrement dans une zone, et une version itérative pour traiter tous les enregistrements dans une zone. La plupart du traitement des écrans est prise en charge par les librairies de runtime. 4.4 Caractéristiques disponibles à l'installation de postgreSQL Les quatre premières caractéristiques peuvent être installées à l'aide du préprocesseur ecpg. Cela permet d'utiliser des variables de programme natives, on n'a pas à s'inquiéter de l'allocation mémoire, parce que la librairie de runtime s'en charge, et les mises à jour peuvent aussi être faites à l'aide des variables-programme sélectionnées. Ce qui manque, c'est une forme spéciale d'instruction include. Maintenant il vous faut connaître quels champs se trouvent dans une table si on veut utiliser une commande 'exec sql declare'. Ce serait mieux s'il y avait quelque chose comme 'exec sql copy fields from <tablename>'. Si les définitions de table changent alors, la recompilation du programme réajustera les définitions. L'usage du programme pgaccess (sous X-window) permet l'accès au dictionnaire de données d'une façon plus élégante. 4.5 Résumé J'ai commencé à écrire une critique de postgreSQL à cause de la documentation très succinte qui est jointe au paquetage. Cela rend plutôt difficile de trouver et d'utiliser tous les composants qui apportent des fonctions additionnelles. J'ai commencé à décrire mes expériences sur d'autres plateformes pour estimer ce qu'un environnement de production devrait fournir à un programmeur. Puis j'ai commencé à examiner soigneusement la documentation livrée et à ma surprise, tous les composants dont j'avais besoin étaient en fait dans le paquetage. La critique suivante demeure cependant encore. La documentation du paquetage est trop fragmentée, et la plupart de la documentation est centrée autour d'aspects techniques qui n'intéressent pas le programmeur de production. C'est cependant compréhensible. La documentation est écrite par ceux qui l'implémentent. Je sais par expérience personnelle qu'écrire un manuel de l'utilisateur est très difficile et qu'il est facile de se perdre dans les détails techniques de l'implémentation qu'on connaît bien. Les parties suivantes sont importantes pour le programmeur de production, et leur documentation devrait être mieux intégrée. Le processeur psql. C'est un bel outil pour définir tous les objets nécessaires dans une base de données, pour se familiariser avec SQL, et pour tester des idées et vérifier des jointures et des requêtes. Le préprocesseur ecpg. C'est l'outil de production principal pour écrire des applications qui utilisent des instructions de manipulation de base de donnée. Cette capacité devrait probablement être étendue à d'autres langages aussi. Puisque tous les liens depuis le champ de saisie sélectionné sont faits vers des variables programme, les enregistrements peuvent être travaillés sans la corvée de les convertir de l'ASCII ou vers l'ASCII, et les mises à jour peuvent être faites à l'aide de l'instruction 'exec sql update'. Le paquetage pgaccess. Le paquetage pgaccess fournit l'accès à toutes les parties de la base de données et offre la possibilité de construire des écrans et des rapports. Il est encore en phase de développement. J'espère qu'il sera étendu dans le futur, parce que l'idée de base est excellente et que les premières implémentations valent le détour. La librairie libpq n'a pas vraiment de valeur pour un programmeur de production. Cela devrait être principalement un outil à utiliser pour implémenter des environnements intégrés et des langages d'accès à la base de données. On pourrait par exemple l'utiliser pour créer un environnement semblable à xBase (pour ceux qui aimeraient l'utiliser). 4.6 Recherches futures Dans les prochaines semaines (mois) j'espère monter un système de base de données complet sur réseau, avec un serveur et plusieurs types de clients (station de travail, terminal, ordinateur distant) à travers plusieurs interfaces (connexions Ethernet, série). Je testerai les diverses plate-formes pour le développement d'applications.. J'ai l'intention d'examiner de plus près les outils fournis dans le paquetage postgreSQL (en développant une base de donnée simple pour ma collection de livres de poche), mais je vais aussi examiner les possibilitésde développement offertes par une plate-forme Java avec JDBC, la conception d'écran et la programmation d'applications. Une dernière note : pour le moment je me concentre sur l'usage d'outils pour lesquels je n'ai pas à payer, parce que j'ai besoin de l'argent pour mes plate-formes matérielles et pour ma maison. Cela ne signifie pas que je sois un partisan endurci du fait que "le logiciel devrait être gratuit". Un environnement de production incite à payer pour du logiciel, parce qu'alors on sait qu'on a un outil complet avec du support et une garantie (malgré les histoires d'horreur concernant le support défaillant). _______________________________________________________________________________ Copyright © 1999, Jurgen Defurne Publié dans le numéro 36 de la Linux Gazette, janvier 1999 Adaptation française : Georges Khaznadar. Page suivante Page précédente Table des matières