Fichiers de configuration des tables de la base

Introduction

La création d'une table est faite, dans le progiciel, par l'intermédiaire d'un outil nommé valfil. Cet outil est appelé directement par l'environnement de développement intégré à ADONIX, dans différents cas : création d'une table depuis l'éditeur des tables, modification d'une table depuis la même fonction, extraction ou intégration de données, intégration d'un patch conduisant au changement de structure d'une table de la base.

A la base, une table est définie par des fichiers physiques se trouvant dans le répertoire FIL du dossier, et par une table de la base de données. Les fichiers physiques sont les suivants :

• un fichier XXX.srf, qui contient la description de la structure du fichier (sous un format « ascii »décrit ci-dessous).
• un fichier XXX.fde, qui contient la description de la structure du fichier (sous forme compilée utilisable directement par le moteur adonix).

Lorsque la table n'est pas stockée dans la base, mais a été déchargée sous forme d'un fichier transportable, on trouvera ses données sous la forme de deux ou trois fichiers supplémentaires :

• un fichier XXX.dat, qui contient les données sous la forme d'un fichier constitué d'enregistrements en longueur fixe.
• un fichier XXX.seq, qui contient le prochain numéro de séquence associé à la table. Cette information est importante dans la mesure où chaque table est associée à un numéro de séquence qui permet de créer des numéros uniques (cela correspond à la fonction adonix uniqid([abv]), où abv est l'abréviation de la table correspondante).
• un fichier XXX.blb, qui contient les données longues (blobs et clobs) s'il en existe dans la table.

Les informations contenues dans ces différents fichiers permettent la création d'une table avec des options « a minima » qui sont les suivantes :

• le dimensionnement de la table (taille prévue, le cas échéant - pour oracle - sous la forme de segment initial et de taille d'extents) est défini dans le fichier d'extension .srf (le calcul étant fait à partir du nombre prévu de lignes dans la table, défini par des variables et formules de dimensionnement).
• le dimensionnement des index est défini par prorata à partir de la taille de la table (on multiplie la taille du segment initial par le rapport entre la longueur de clé et la longueur de la ligne de table, puis on impose le next extent à la même taille que l'initial).
• les groupes de fichiers (sous SQL server) sont ceux définis dans le fichier .adxodbc s'il existe. Si le fichier n'existe pas, on prend les groupes de fichiers DOSSIER_DAT et DOSSIER_IDX s'ils existent, DOSSIER étant le nom du dossier. A défaut, on prend le groupe par défaut défini pour la base.
• les tablespaces de stockage (pour oracle) sont ceux définis dans le fichier .adxora s'il existe. Si le fichier n'existe pas, on prend le tablespace associé par défaut à l'user DOSSIER pour les données, le tablespace DOSSIER_IDX pour les index.

Il peut être intéressant de définir des informations complémentaires utilisées lors de la création de la table et à chacune de ses mises à jour, pour modifier ces règles de dimensionnement ou de localisation, en tenant compte des particularités des différentes bases de données et ainsi obtenir de meilleures performances. Mais ceci suppose de stocker ces éléments hors de la base, afin que l'outil valfil puisse les appliquer à chaque fois qu'une validation ou une revalidation de la table sera faite. C'est pourquoi, il est possible de créer un fichier d'extension cfg dans le répertoire FIL. Ce fichier permet d'enregistrer un ensemble de directives optionnelles qui complèteront l'ordre SQL Create table ou Create Index qui sera réalisé par valfil. Tout comme les fichiers d'extension .srf, il est en format « ascii » (décrit ci-dessous).

Le contenu de ce fichier de configuration apparaît en bas de l'onglet de définition des index, en gestion des tables. La suite de ce document décrit la syntaxe d'écriture de ce fichier de configuration.

Syntaxe d'écriture

Ce fichier est composé de lignes de texte formant des sections. Chaque section commence par une étiquette préfixée par le caractère $, suivi d'un code indiquant pour quelle base de donnée est faite cette section (c'est soit ORACLE, soit MSSQL), suivi d'un caractère de soulignement et du nom de la table ou d'un index.

On y trouve ensuite des clauses encadrées par les caractères {" (accolade ouvrante suivie d'une double quote) et "} (accolade fermante précédée d'une double quote). Ces clauses seront passées telles quelles à la base de données lors de la création ou la modification de la table ou de l'index. S'il en existe plusieurs, elles sont passées les unes après les autres, séparées par une fin de ligne. Le nombre de caractères d'une clause est limitée à 256.

On y trouve ensuite le mot-clé End, qui termine une section.

Des commentaires peuvent être insérés dans le fichier de configuration, sous la forme de textes libres préfixés par le caractère # (dièse). Un commentaire ne peut se trouver qu'en début de ligne.

Dès lors qu'une section non vide (avec au moins une clause) existe, toutes les règles de dimensionnement ou de stockage par défaut de l'élément (table ou index) décrit sont ignorées au profit des clauses passées.

Une section correspondant à un élément inexistant, ou relative à une base de donnée qui n'est pas la base de données courante, est purement et simplement ignorée.

Exemples de syntaxes oracle

Les clauses de stockage peuvent être, par exemple :

Exemples de syntaxes SQL server

La seule clause de stockage possible est :

A partir de la version 6.4, il est également possible de définir que le premier index (et lui seul) est "clustered", c'est-à-dire que les données de la table dont physiquement rangées dans l'ordre de cette clé. Ceci peut être utilisé à des fins d'optimisation, le principe étant alors d'ajouter la section suivante (XXXX étant le nom de l'index en question) :

$CLUSTERED
{ "XXXX" }
End

Il est important, pour que cette directive soit prise en compte, de revalider la table en mode forcé après avoir modifié le fichier de configuration.

Attention : cette syntaxe pour définir l'index "clustered" est temporaire. En effet, dans la prochaine version majeure, la définition des index de ce type sera défini de façon plus naturelle dans le dictionnaire.

Exemple de fichier

On trouvera ci-dessous un exemple de fichier de configuration. On notera qu'ici une partie seulement des directives seront utilisées (selon la base utilisée, puisque seules celles s'appliquant à la base de données réellement utilisée seront mises en œuvre).

Il est à noter que la fourniture standard du progiciel ne comporte aucun fichier de configuration, et qu'une mise à jour respecte les fichiers de configuration existants. En effet, les fichiers de configuration sont considérés comme des éléments d'implémentation et sont forcément liés à une installation donnée et pas à un standard quelconque.

Annexe : les fichiers ascii utilisés avec le moteur ADONIX

Le moteur ADONIX utilise des fichiers ascii de type « Unix », c'est-à-dire que le séparateur de ligne est le Line Feed (caractère de code 10), et non par Carriage Return, Line Feed (caractères 13, puis 10) comme pour les fichiers textes Windows™. Il est donc fondamental de ne pas éditer de tels textes sous notepad (ou du moins de ne pas les réécrire avec notepad), faute de quoi le moteur adonix serait en peine de les réexploiter. Par contre, sous UNIX, l'éditeur vi est utilisable. Les éditeur adonix gèrent tout à fait correctement ces fichiers.

Il est par ailleurs à noter que le format utilisé par ces fichiers est en réalité le format UTF8 (qui est un format permettant de traiter les caractères UNICODE - chinois par exemple - de façon totalement transparente. Il s'agit donc en réalité d'un codage sur 1 à 4 octets pour un seul caractère. Le format UTF8 correspond à l'ASCII pour tous les caractères non accentués, mais dès que le bit de poids le plus fort est1, le caractère est codé sur plus d'un octet. Ceci signifie que les caractères accentués français ne sont pas visualisés correctement avec les éditeurs « classiques » (mais les éditeurs adonix traitent tout à fait correctement ce transcodage).

Annexe : les règles de dimensionnement  par défaut des tables

En l'absence de fichier de configuration, l'algorithme de dimensionnement utilisé pour tailler les tables oracle est le suivant :

• on détermine d'abord le nombre de lignes susceptibles d'être stockées dans la table. Ce nombre de lignes est calculé par le biais des formules de dimensionnement, elles-mêmes calculées à partir d'éléments de dimensionnement. Ce nombre de lignes est comparé avec le nombre de lignes données dans la rubrique Nombre de fiches situées dans le premier onglet du dictionnaire des tables. C'est le maximum des deux nombres qui est retenu.
• on calcule ensuite la taille d'une ligne de la table en nombre d'octets. On considère pour ce faire le type interne associé à chacun des types de données des champs de la table. Un champ de type libellé prend 1 octet, un champ de type entier 2 octets, un champ de type entier long 4 octets, un champ de type décimal 8 octets. Les champs de type alphanumériques et de longueur maximale L prennent L+1 octets, multiplié par un coefficient multiplicateur qui vaut 1 si la base est en ASCII, et qui vaut la valeur de la variable d'environnement STUSIZE si la base est UNICODE (en l'absence de valeur, on prend 2). Il est à noter que cette taille peut être obtenue par la fonction Option / Informations accessible en gestion des tables.
• on calcule de même la longueur (en octets) de chaque index, en appliquant les mêmes règles de dimensionnement pour les champs qui le composent.
• on calcule la taille globale de la table en multipliant le nombre de lignes par la taille d'une ligne, et en appliquant un coefficient pour tenir compte du fait que le remplissage n'est jamais maximal (ce coefficient vaut 0,5 par défaut).
• dans le cas de la base de données oracle, on définit la taille du segment initial en prenant la taille de la table si elle est inférieure à 10 Mo. Sinon, on limite le segment initial à une valeur donnée par la variable d'environnement ADXEXTSIZE (exprimée en K-octets). Cette valeur ne peut en aucun cas être supérieure à 1,5 Goctets.