Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Programmez! - N°98 JUIN 2007 32 Dossier SGDB PROGRAMMATION LINUX L 'utilisation

Programmez! - N°98 JUIN 2007 32 Dossier SGDB PROGRAMMATION LINUX L 'utilisation d’une base de données a permis de simplifier et nor- maliser cette gestion pour les développeurs. Malgré cet intérêt, son utilisation a longtemps été limitée aux applications critiques et complexes du fait notamment des coûts induits ainsi que des com- pétences nécessaires à l’installation et à l'administration. L'installation et l'administration des bases de données se sont pro- gressivement simplifiées, ce qui a eu pour effet de répandre leur utili- sation, et plus récemment l'apparition de bases de données Open Source a complètement démocratisé leur utilisation à toutes sortes d’applications, simples ou complexes, critiques ou non critiques. Pour définir simplement une Base de Données, nous pouvons parler de collection de données inter reliées de façon cohérente. Un Système de Gestion de Bases de Données (SGBD) est un ensemble de programmes qui permettent à des utilisateurs de saisir, d’organiser et de sélection- ner des informations dans la base de données. Le SGBD le plus courant est un système de gestion de base de données relationnelle ou SGBDR, c'est est un logiciel capable de traiter des don- nées structurées (tables, lignes, colonnes) dans un contexte de concur- rence d'accès. Les grandes caractéristiques d'un SGBDR sont : - Indépendance face au type de stockage - Indépendance des données face aux applications - Accès efficace aux données - Gestion de l'aspect transactionnel et des accès concurrents - Manipulation des données simplifiées (Langage SQL) - Assurance de la cohérence des données - Sécurité physique (Reprise cohérente en cas d'incident) - Sécurité logique (Gestion des droits, limitation d’accès, etc.) Le Langage SQL permet de dialoguer avec un SGBDR. Le succès du lan- gage SQL est dû essentiellement à sa simplicité d’utilisation et au fait qu’il s’appuie sur le schéma conceptuel pour énoncer des requêtes en laissant le SGBD responsable de la stratégie d’exécution. Ce langage permet d'effectuer diverses opérations comme la création, l'extraction, la modification, la suppression, la fusion, etc., sur des collections de données. Le langage SQL sera normalisé à cinq reprises (SQL 86, SQL89 SQL 2, SQL 3, SQL 2003). Les SGBDR de notre étude Les SGBDR abordés dans cette article sont IBM DB2 V9, Oracle 10g, Sybase ASE 15 et Microsoft SQLServer 2005, MySQL v5.0 et PostgreS- QL v8. Hormis Microsoft SQL Server, disponible uniquement sur Win- dows, les autres éditeurs proposent des distributions sur les plates-formes les plus utilisées (Windows, AIX, HPUX, Solaris, GNU Linux, etc.). Ces distributions sont disponibles soit sous forme de binaires, soit sous forme de sources à recompiler. Actuellement, plus de 50 % des serveurs supportant des bases de données utilisent Win- dows. Linux connaît une forte progression par rapport à UNIX. Dans les SGBDR pris en compte pour cet article, les bases Mysql, PostgreSQL et MS SQL sont les distributions les plus simples à installer. De ce point de vue, MySQL a un net avantage à travers les packages de type Wamp ou Lamp qui associent, en plus du serveur de bases de don- nées MySQL, un serveur apache et les bibliothèques PHP. Ce type de package le rend très attractif pour un développeur qui a choisi ce langa- ge. Les SGBDR historiques sont plus complexes à installer en fonction de la plate-forme choisie et demandent des connaissances préalables plus importantes. Développer avec un SGBDR Tous les SGBDR sont capables de dialoguer avec les langages de déve- loppement les plus courants (C, C++, PHP, Java. .NET, Perl, etc.). Le dia- logue avec la base de données s’effectuera à travers des requêtes SQL dynamiques ou encapsulées dans des objets compilés (procédures stockées, fonction etc.). Afin de pallier une carence de la norme SQL, chaque éditeur a depuis toujours développé un langage complémentaire (SQL étendu) permettant notamment de gérer la notion de variable et de contrôle de flux (test, boucle …). L’utilisation des objets compilés comme les procédures stockées ou les Choisir sa base de données La gestion du stockage de l'information a toujours été un élément critique de toute application infor- matique. La gestion des fichiers, la recherche de l'information a très souvent complexifié les déve- loppements. Comment choisir ? Quels critères retenir ? Programmez! - N°98 JUIN 2007 33 Dossier SGDB PROGRAMMATION LINUX triggers permettant de faciliter la maintenance, la sécurité et la perfor- mance de traitements critiques, Par contre leur utilisation lie fortement l’application à l’éditeur du SGBDR. En effet, la syntaxe d’écriture d’un objet compilé n’est pas compatible d’un éditeur a un autre (hormis entre Sybase et MS SQL qui utilisent le même langage étendu, ce qui permet un certain niveau de compatibilité). Le tableau ci-dessous liste les fonctionnalités de base nécessaires pour un développement et le niveau de compatibilité avec la norme SQL SQL DB2 Oracle Sybase SERVER MySQL PostgreSQL Norme SQL SQL92 SQL92 SQL92 SQL99 SQL92 En partie et SQL99 et SQL99 et SQL99 et SQL99 SQL2003 SQL Etendus SQL PL PL/SQL Transact Transact SQL SQL SQL PL/pgSQL Richesse du langage étendu Très riche Très riche Riche Riche moyen Riche Transaction OUI OUI OUI OUI OUI OUI Procédures stockées OUI OUI OUI OUI OUI OUI Trigger OUI OUI OUI OUI OUI OUI Curseurs OUI OUI OUI OUI OUI OUI Vues OUI OUI OUI OUI OUI OUI Union OUI OUI OUI OUI OUI OUI Fonctions (UDF) OUI OUI NON OUI OUI OUI Contraintes OUI OUI OUI OUI OUI sur OUI les moteurs Innodb et Ndb Cluster Les SGBD sont aujourd’hui des produits matures et les fonctionnalités de base pour le développement actuellement mises en œuvre par les éditeurs sont sensiblement équivalentes. Les éditeurs historiques ainsi que PostGreSQL proposent un langage étendu très complet. MySQL propose un langage étendu moins riche, mais suffisant. Il faut également noter que certaines fonctionnalités sont, relativement aux éditeurs historiques, très récentes sur le SGBD MySQL. Par exemple, les procédures stockées ou triggers ne sont dis- ponibles que depuis la version 5 et sont actuellement encore peu implé- mentées, alors que sur tous les autres moteurs, l’utilisation des objets compilés est très courante. Il est à noter que les SGBD Open Source sont ceux qui suivent au plus près les normes SQL (PostgreSQL a implé- menté une partie de la norme Sql 2003) MySQL a une approche spécifique, reposant sur plusieurs moteurs de stockage ; chacun répondant à des spécificités particulières et optimisé pour un mode d'utilisation (non transactionnel avec Myisam, transac- tionnel avec Innodb etc). Unicode Le stockage classique de jeux de caractères de type latin-1, cp850 ou ISO 8859-1 se fait sur 1 octet, ce qui ne permet pas de stocker des jeux de caractères complexes. Le standard Unicode est un mécanisme uni- versel de codage de caractères. Il définit une manière cohérente de coder des textes multilingues et facilite l’échange de données tex- tuelles. Obligatoire pour la plupart des nouveaux protocoles de l’Inter- net, il est mis en œuvre dans tous les systèmes d’exploitation et langages informatiques modernes, Unicode est la base de tout logiciel qui veut fonctionner aux quatre coins du monde. Les SGBDR ont, bien sûr, implémenté à différents niveau les normes permettant de gérer l'unicode ( UCS-2, UCS-4, UTF-8, UTF-16 ). SQL DB2 Oracle Sybase SERVER MySQL PostgreSQL UTF-8 OUI OUI OUI OUI OUI UTF-16 OUI OUI OUI OUI UTF-32 UCS-2 OUI OUI UCS-4 L’utilisation du stockage unicode se fera essentiellement à travers les types NCHAR et NVARCHAR. Tous les SGBDR sont capables à différents niveaux de traiter l’UNICODE. La gestion du "caractère set" et du langage peuvent être gérées à tra- vers la notion de collation au niveau de la colonne pour MySQL et MS SQL Server. Les autres SGBD gèrent ces paramètres au niveau de l'ins- tance ou au plus fin au niveau de la base. XML XML (eXtensible Markup Language) est une norme d'échange de docu- ments informatisés et est rapidement devenu un standard pour structu- rer les documents à transférer et à échanger à travers un réseau. XML est le standard émergent pour l'intégration de données en SOA (Archi- tecture Orientée Services). Le SGBDR n’est pas forcément le moteur de stockage idéal pour les documents XML auquel nous préférerons des bases "natives" de type hiérarchique, explicitement construites pour stocker du XML. Toutefois, les bases relationnelles proposent deux solutions pour stoc- ker les documents XML. La première stocke le document en bloc dans le champ d´une table tandis que la seconde extrait l´information du document pour la décomposer et la ranger dans différentes tables et champs. La première solution préserve l´intégrité du document, par contre, elle rend difficile la manipulation des données à l'intérieur du document. La seconde simplifie la manipulation des données, mais elle ne permet pas de conserver le document dans sa forme originale et oblige donc à un mapping de schémas et des requêtes complexes pour les restituer. Si nous voulons conserver l’intégrité du document et faciliter la manipu- Programmez! - N°98 JUIN 2007 34 Dossier SGDB PROGRAMMATION LINUX lation nous serons par conséquent obligés, dans un moteur relationnel, d’effectuer un double stockage coûteux. Une fois les documents stockés, il faudra pouvoir manipuler les formats XML. Pour uploads/Management/ comment-choisir-son-sgbd.pdf