l est très fréquent de devoir mettre en ligne une base de données. Dans certains cas les données sont antérieures à la création du site web. Il nous faut donc leur imposer une migration et ce quelque soit la saison. Je vis donc brosser la problèmatique de ces transferts d'informations d'un SGBD à un autre.

Effectivement je ne vais pas aborder le cas où le SGBD de la base en ligne est le même que celui utilisé en local. Je vais donc me concentrer sur la situation fréquente des structures qui ne peuvent pas, pour diverses raisons, choisir leur SGBD-web. Cela viendra souvent du fait qu'en hébergement mutualisé, on prend ce que l'on nous propose.

Il y a deux grandes solutions possibles pour transférer les données, soit passer par un fichier à plat intermédiaire, soit lire et écrire au fur et à mesure.

Je n'aborde pas ici, la construction du schéma de la base cible. Elle peut avoir ou non la même structure. De plus, les formats des données n'ont pas toujours leur équivalents, sauf à respecter les standards.

On va considérer qu'un fichier à plat est un fichier que l'on peut lire sous éditeur de texte, ce n'est pas toujours le cas. Mais dans la situation qui nous préoccupe, ce le sera. On parle aussi de fichier de déchargement, on a déchargé, vidé la base de données. On va en faire un rechargement.

Les fichiers à plat les plus connus sont les fichiers "format délimités". la plupart des logiciels savent exporter et importer de tels fichiers. Parmi ceux-ci, il y a les fichiers CSV. Chaque uple de la table donne une ligne dans le fichier texte, et les champs sont séparés par des ';'. Les champs textes peuvent être encadrés par de ", le guillemet double. Il suffit d'exporter sous ce format à partir du SGBD source et de faire importer dans le SGBD cible. Même si un tableur (Excel par exemple) n'est pas un SGBD(1), il autorise l'export dans ce format. Ce qui s'avère utile quand les données doivent être construites de façon algorithmique, un tableur se place bien là.

Nous allons rencontrer cette situation dans le cas de bases bureautiques qui doivent être mises sur le web. Bien souvent qui dit bureautique dit Windows et Access ; alors que l'hébergement à coût réduit sera souvent sous Linux (2). On va donc exporter chacune des tables au format CSV et faire relire ce fichier au préalable transféré par le SGBD. A condition d'avoir une interface de pilotage de la base de données.

Il y a deux limites à ce système la correspondance entre tables, il faut que les tables aient exactement la même structure. On en est parfaitement maître, il n'y a que peu de raison pour que le web vienne mettre en cause l'organisation du schéma de la base. L'autre est plus rédhibitoire, c'est la volumétrie. Si la table est très grosse, le fichier peut devenir conséquent et le rechargement devient alors trop long et on tombe en time-out. On ne peut pas souvent joué sur ce paramètre surtout en hébergement mutalisé.

On est donc obligé de morceller le fichier, en faisant attention aux reprises.

Nous allons étudier l'autre méthode.

Je devrais plutôt dire préparation à l'écriture. Cette technique est surtout utile - nécessaire - pour gérer les changements de structure des tables, car nous pouvons formater les données comme nous voulons. L'objectif est de préparer des fichiers de commandes SQL à faire exécuter par le SGBD cible.

Le standard d'insertion SQL est
INSERT INTO table ( col1, ..) VALUES ( xxx, ..);

On va donc écrire un programme/script qui va nous préparer ces requêtes d'insertion. On propose ensuite ce fichier de requêtes au loader, à l'interface avec le SGBD cible.

On peut aussi les passer au fur et à mesure, c'est ce que je fais entre mon poste local et le serveur. Cette solution est intéressante pour les gros volumes de données, pour les chargements récurrents. Et c'est en fonction des disponibilités de langages, de nos compétences propres, des systèmes d'exploitation auxquels nous avons affaire que nous choisirons le langage de scripts, la machine où il tournera etc.. Mais elle nécessite d'avoir un accès simultané sur les deux machines, et cela un serveur web sur les deux.

Bonne lecture, à bientôt sur le forum ou par messagerie.

(1) Excel est un tableur, il organise les données en tables avec des lignes et des colonnes. Mais les colonnes ne sont pas typées, et ne peut pas être interrogé en natif par SQL, même si l'on peut passer par ODBC.

(2) N'entamez pas le débat sur la comparaison des coûts d'hébergement, il ne s'agit pas de définir les généralités mais bien de répondre à des particularités.

Daniel Lucazeau
Ajornet.com
Chef de projet Internet
Développeur informatique

Tous droits réservés - Reproduction même partielle interdite sans autorisation préalable