5 - InterBase 5.0
Qu'est-ce qu'InterBase 5.0 ?
Serveur actif
Evolutivité et portabilité
Client/Serveur à deux niveaux
Technologie InterBase Conformité SQL-92
Extensions SQL
Isolation des transactions
Transactions distribuées et validation automatique en deux phases
Architecture multigénération et verrouillage de bas niveau
Blobs et tableaux
Fonctions définies par l'utilisateur (UDF)
Optimiseur de requête
Evènements
Sécurité des bases de données
Support de l'international
Outils client/serveur d’Inprise
Interface ODBC
InterBase est un système de gestion de bases de données relationnelles complet, implémenté sous forme d'une
architecture client/serveur à deux niveaux : une application client et une technologie serveur offrant un support
transparent au travers de réseaux hétérogènes. Cette architecture flexible permet d'intégrer le moteur de base de
données InterBase à une application verticale.
Les fonctionnalités de serveur actif d'InterBase se prêtent elles-mêmes aux opérations automatiques, de sorte que
nous n'avons pas besoin d'administrateur dédié à la base de données. InterBase est de loin le serveur SGBDR le plus
simple d'emploi.
L'intégration d'InterBase aux meilleurs outils de développement client/serveur et son implémentation des standards
de l'industrie en font le choix idéal pour le développeur d'applications intégrées et orientées données.
Serveur actif
InterBase a été le pionnier du concept de serveur actif, qui permet à la base de données elle-même de contenir les
règles de gestion et de fonctionner comme gestionnaire central d'accès simultanés pour de nombreux clients. Voici
les fonctionnalités d'InterBase qui supportent le concept de serveur actif :
• Des procédures stockées SQL implémentent sur le serveur des opérations de bases de données partagées,
modulaires et respectant la sécurité.
• Des alerteurs d'événements informent les clients des modifications de la base de données.
• Le serveur maintient l'intégrité des données selon des règles d'intégrité référentielle déclarative avec des
opérations en cascade.
• La validation (commit) en deux phases stabilise les transactions multibases de données distribuées.
Evolutivité et portabilité
InterBase implémente son interface de développement et sa technologie via une variété de configurations de plates-
formes, assurant des fonctionnalités identiques. Cela garantit l'interopérabilité transparente des plates-formes
hétérogènes et une migration en douceur lorsque les bases de données sont portées de la station de travail vers le
serveur d'un groupe de travail ou d'un département. Les plates-formes supportées par InterBase 5.0 sont :
Windows 95
Windows NT 4.0 sur plate-forme Intel
Sun Solaris sur plate-forme SPARC
Hewlett Packard HP-UX
En outre, les plates-formes suivantes sont supportées par InterBase 4.0 et peuvent l'être en passant aux versions
5.x d'InterBase :
Windows 3.1x
Novell NetWare
SCO OpenServer version 5.0
IBM AIX RS/6000 et PowerPC
Autres fournisseurs UNIX
DEC OpenVMS sur Alpha
InterBase occupe un très faible encombrement, ce qui permet au logiciel de fonctionner aussi bien sur de modestes
plates-formes que sur des serveurs milieu de gamme. L'installation minimale requiert moins de 3 méga-octets
d'espace disque, alors que l'installation complète, avec tous les exemples et la documentation en ligne, nécessite
moins de 20 méga-octets. Le serveur InterBase gère sans problème jusqu'à 150 clients simultanés.
InterBase 5.0 comprend une installation client/serveur pour une des plates-formes ci-dessus et une bibliothèque
client Windows 32 bits. Le client et le serveur peuvent communiquer par le biais des protocoles réseau suivants :
Une plate-forme client quelconque peut communiquer de façon transparente avec n'importe quelle plate-forme
serveur.
La bibliothèque client fournit une API pour que les applications client puissent soumettre des requêtes à InterBase et
récupérer des données lorsqu'InterBase fonctionne sur un serveur NT, UNIX ou NetWare. La bibliothèque client
implémente un protocole spécial, optimisé pour le réseau, pour communiquer avec le service InterBase distant. Les
outils Inprise fournissent un accès transparent à la bibliothèque client InterBase via le BDE (Borland Database
Engine).
InterBase pour Windows peut également être exécuté comme un moteur de bases de données locale, autonome,
incorporé dans une application Windows. Cette configuration est appelée serveur InterBase local. Elle ne fait appel à
aucun protocole réseau ; à la place, la bibliothèque client communique avec InterBase local par le biais d'une
communication locale interprocessus.
InterBase implémente le niveau de base du standard SQL-92, ainsi que de nombreuses fonctionnalités issues du
niveau intermédiaire et des fonctionnalités sélectionnées dans le niveau complet. InterBase possède le statut de
membre votant dans le comité des standards ANSI SQL, H4. Les fonctionnalités SQL notables sont :
· Rôles SQL pour offrir des privilèges de sécurité à des groupes d'utilisateurs
Extensions SQL
Des fonctionnalités d'InterBase avancées, comme les procédure stockées, ont servi de modèle au standard SQL-3
pour les objets de base de données. Les extensions notables à SQL implémentées dans InterBase sont :
Fonctionnalité Description
Procédures stockées Modularise les opérations de bases de données complexes
Procédures select Renvoie les ensembles de résultats des requêtes
Définitions de domaines Etend les types SQL de base
Déclencheurs Automatise les règles de gestion
Générateurs Implémente l'incrémentation automatique des valeurs entières
Toutes les opérations de bases de données dans InterBase surviennent dans le contexte d'une transaction, comme
dans tous les SGBDR complets. La transaction fournit un mécanisme pour isoler les modifications faites par une ou
plusieurs opérations jusqu'à ce que l'application client valide (commit) la transaction. Cela se traduit également par
la possibilité d'annuler (rollback) la transaction, ce qui annule toutes les modifications faites par les opérations qui
sont dans le contexte de cette transaction.
Une application client peut supporter un nombre quelconque de transactions simultanées actives avec une base de
données. Chacune a son propre contexte et sa propre opportunité de validation ou d'annulation. Cette possibilité de
plusieurs transactions simultanées pour chaque client est caractéristique d'InterBase.
Non seulement une base de données peut avoir plusieurs transactions d'un seul client, mais InterBase permet à un
client d'avoir une seule transaction qui opère sur plusieurs bases de données, pouvant même résider sur des
serveurs distincts. La bibliothèque client InterBase gère de façon transparente toute cette "comptabilité". Si
l'application client est connectée à plusieurs bases de données, lorsqu'elle lance une transaction, celle-ci est
automatiquement définie en tant que transaction distribuée. D'une certaine façon, c'est une transaction virtuelle,
correspondant à une vrai transaction pour chacune des bases de données. Le client InterBase garde la trace de tout
cela, ce qui permet au développeur de l'application de maintenir une vue identique à celle d'une transaction
distribuée. Aucune programmation particulière n'est requise.
Lorsque vous validez ou annulez une transaction distribuée, la bibliothèque client doit s'assurer que toutes les
transactions sont résolues de la même façon. Le but d'une transaction est de maintenir un contexte atomique pour
les opérations de bases de données, et il serait fatal pour cette intégrité de permettre à une transaction distribuée
d'être validée dans une base de données pendant que la validation échoue dans une autre. InterBase réalise cela en
utilisant un processus de validation en deux phases. Pour chaque base de données, la transaction est préparée pour
la validation (ou éventuellement pour l'annulation). Une fois que toutes les transactions sont marquées préparées,
une deuxième phase les fait passer de préparées en validées (ou annulées). Ce mécanisme est encore une fois
transparent pour le développeur de l'application ; aucun code particulier n'est requis.
L'architecture MGA (Multi-Generational Architecture) unique d'InterBase, appelée aussi versioning, autorise de
nombreux accès client simultanés à un serveur InterBase et de gros débits. De plus, la façon dont InterBase stocke
plusieurs versions d'un enregistrement de données signifie que chaque client a une vision cohérente de la base de
données. Un client peut mettre à jour les données sans interférer avec la vue des données qu'ont les autres clients.
Ces fonctionnalités aboutissent à une technologie de SGBD convenant parfaitement à la gestion des transaction
courtes, fréquentes dans le modèle OLTP, ainsi que des transactions de longue durée de type OLAP.
Le serveur implémente de vrais verrous de bas niveau, en utilisant la stratégie du verrouillage optimiste. Un nombre
quelconque de clients peuvent partager l'accès simultané en lecture à un enregistrement ; le conflit se produit
seulement quand deux clients tentent de mettre à jour le même enregistrement. Dans ce cas, le client qui avait
lancé l'opération de mise à jour le premier a la possibilité de la valider et le serveur renvoie une erreur à l'autre ou
aux autres clients.
La combinaison du versioning et du verrouillage de bas niveau donne à InterBase des capacités de simultanéité et de
débit exceptionnelles, comparées aux implémentations de SGBD utilisant les verrous au niveau de la page ou les
verrous exclusifs en lecture. Les accès en lecture ne bloquent jamais les accès en écriture, et les accès en écriture ne
bloquent jamais les accès en lecture.
InterBase gère à la fois le versioning et le verrouillage de façon transparente et automatique pour l'application. Cela
libère le développeur du contrôle manuel du verrouillage obligatoire dans d'autres SGBDR. De nombreux paramètres
facultatifs pour les transactions permettent aux développeurs d'adopter une autre politique de verrouillage.
Blobs et tableaux
InterBase a inventé l'implémentation d'un type de données à taille et contenu variables, le type Blob. Les blobs
peuvent occuper plusieurs giga-octets. Les applications peuvent manipuler les blobs volumineux segment par
segment afin d'éviter la surcharge des ressources du client sur le réseau. Nous pouvons assigner aux colonnes des
blobs des sous-types définis par l'utilisateur, pour identifier et différencier des types particulier de données
structurées et les stocker dans les blobs non structurés.
Les types de tableaux d'InterBase sont liés aux blobs. Nous pouvons concevoir dans la base de données une colonne
contenant un tableau multi-dimensionnel de type SQL standard, et utiliser des instructions SQL pour interroger le
contenu des tableaux. Un tableau InterBase est implémenté comme un blob structuré, ce qui lui permet d'avoir une
taille quasi illimitée.
Nous pouvons augmenter les fonctionnalités du serveur InterBase en ajoutant nos propres modules
compilés et en utilisant des fonctions dans les requêtes et dans les procédures stockées. Le code compilé
écrit en C, C++ ou Delphi, dans une bibliothèque partagée (UNIX) ou dans une DLL (Windows), place la
bibliothèque sur le serveur de bases de données et définit le point d'entrée de la fonction dans la définition
de la base de donnée. Nous pouvons alors appeler les fonctions de la bibliothèque par SQL. InterBase
nous permet d'ajouter un nombre quelconque de bibliothèques de UDF sur un serveur (nombre limité
seulement par le système d'exploitation) et de les utiliser simultanément.
Les filtres Blob sont également une extension compilée du serveur. La fonction des filtres Blob est de convertir un
sous-type Blob en un autre. Pour chaque combinaison de deux sous-types Blob, nous pouvons définir une fonction
dans une bibliothèque compilée, conçue pour convertir les données d'un format structuré en un autre. Par exemple,
nous pouvons définir un sous-type Blob pour qu'il contienne une image au format GIF et un autre sous-type pour un
fichier JPEG. Nous pouvons programmer un filtre Blob convertissant les données d'un format dans un autre, et quand
nous copions le contenu d'une colonne du Blob dans celle d'une autre base de données, le serveur appelle
automatiquement le filtre Blob pour effectuer la conversion.
Optimiseur de requête
InterBase comprend un optimiseur de requêtes SQL sophistiqué côté serveur. En se basant sur un algorithme
d'analyse des coûts, le serveur InterBase essaie de faire le meilleur usage des index définis dans des tables de bases
de données, pour effectuer les recherches et les tris des clauses SQL JOIN, DISTINCT, ORDER BY et GROUP BY, et
pour exécuter la requête de la façon la plus efficace possible.
Evènements
Le serveur actif peut fournir des applications client avec la notification des événements de bases de données définis
par l'utilisateur. Les applications client indiquent l'intérêt pour un événement en mémorisant son nom. L'événement
est envoyé par l'instruction POST dans le code d'un déclencheur ou d'une procédure stockée. Tout client qui a déclaré
un intérêt pour cet événement est immédiatement prévenu par le serveur. Il existe des mécanismes pour que les
clients attendent l'événement (notification synchrone), ou bien poursuivent le traitement et soient prévenus par une
fonction de rappel (notification asynchrone).
InterBase autorise les accès pour effectuer des opérations sur les données en accordant des privilèges SQL standard
aux noms d'utilisateur. Ces noms d'utilisateur sont définis par serveur et stockés dans une base de données
InterBase spéciale. InterBase supporte également les Rôles SQL, un mécanisme pour constituer des groupes
d'utilisateurs auxquels on peut accorder des privilèges.
Sur les serveurs UNIX, InterBase s'intègre au système d'exploitation en permettant d'accorder des privilèges SQL
aux noms d'utilisateur et aux noms de groupe UNIX, en plus des utilisateurs définis spécifiquement pour InterBase.
Support de l'international
InterBase stocke désormais de nombreux jeux de caractères internationaux et utilise leur ordre de tri respectif, ainsi
que le standard UNICODE-FSS. Cela confère à InterBase une capacité remarquable à supporter les applications de
bases de données internationales. Des jeux de caractères et des ordres de tri peuvent être définis au niveau de la
base de données toute entière ou au niveau d'une table. En outre, l'ordre de tri peut être spécifié pour une requête,
au moment voulu. Le serveur envoie les données au client, et c'est l'application client qui se charge de les afficher de
la façon appropriée.
Le moteur de bases de données Inprise (BDE) intègre InterBase à Delphi, C++Builder, IntraBuilder et Visual dBase,
qui sont les meilleurs outils de développement visuel pour Windows. Les contrôles orientés données, qui font partie
de la technologie RAD d’Inprise, sont directement intégrés au méthodes d'accès aux bases de données du BDE.
InterBase est livré avec les versions Professionnelle et Client/Serveur des outils Inprise. Cela permet d'offrir une
solution complète aux développeurs de logiciels client/serveur qui utilisent les outils Inprise.
Interface ODBC
InterBase 5.0 pour Windows comprend un pilote ODBC 32 bits personnalisé de Visigenic Software, Inc. Ainsi, toute
application de gestion qui utilise des sources de données ODBC peut accéder à une base de données InterBase. Ce
pilote est conforme au standard ODBC 2.5.
Historique
Que ce soit pour l'une ou l'autre de ces raisons, vous serez intéressé d'apprendre qu'InterBase est né des
travaux d'un développeur de Rdb de DEC, Jim Starkey. Souhaitant plus de liberté dans l'évolution de son
produit, il créa et dirigea InterBase Inc. Ashton-Tate acheta la société. Et quand Borland racheta cette
dernière, elle devint propriétaire d'InterBase. Plus récemment Borland/Inprise fit d'InterBase une entité
autonome et décide l'été 2000 de mettre InterBase en Open Source.
Aujourd'hui, InterBase est donc soutenue d'une part au sein de Source Forge® ou d' IBPoenix, d'autre part
par Inprise. Bien que le produit soit devenu libre de droit d'usage et de diffusion, Borland/Inprise continuera
de certifier et de vendre InterBase. C'est une garantie pour ceux qui ne veulent ou ne peuvent prendre le
temps de valider les innovations proposées par l'Open Source. Tandis que pour ceux qui adoptent la
version Open Source, la présence de Borland/Inprise est une garantie de convergence et d'intégration du
produit. Début Octobre 2000, la version vendue est la 5.5, la version en Open Source la 6.01 . La présence
simultanée d'un groupe d'initiatives Open Source et d'un acteur commercial est le meilleur modèle de
développement d'un progiciel. Loin de s'opposer, ils s'appuient l'un sur l'autre et se renforcent. (C'est
d'ailleurs le modèle que Linux est en train d'adopter).
Evidemment, il vous faut aussi InterBase 6.01 que vous pouvez télécharger à partir du site de Borland.
Installation
Pour installer InterBase sur votre poste de travail, exécutez le fichier IBWin32.exe :
Sur la page Select Components, cochez InterBase 6.0 Server for Windows
(et laissez coché InterBase 6.0 Client for Windows ainsi que les autres options)
Sur la page ODBC Components, laissez coché InterBase ODBC 3.0 Driver.
Installez ensuite les dernières versions des composants InterBase Express et IBConsole.
Cliquez sur Ok. L'icône Local Server doit apparaître maintenant dans le volet gauche de l'explorer.
La connexion étant ouverte, vous voyez apparaître Databases dans le volet gauche. Par menu
Database/CreateDatabase, ouvrez le panneau de création de la database.
Indiquez le nom d'alias, ainsi que le nom du fichier (avec l'extension .gdb)
Par la suite, lorsque vous réouvrirez IBConsole, vous double-cliquez directement Local Server, puis
MyInitialDatabase.
Par menu Database/Properties, puis onglet General, mettez l'option Forced Writes à Enabled.
De retour dans l'explorer d'IBConsole, vous voyez les différentes composantes d'une database :
Vous êtes devant une DBGrid. Voyons maintenant comment intégrer une table dans un programme Delphi.
Programme Delphi
Créez un projet Delphi. Ajoutez un Module de données (DataModule). A partir de l'onglet InterBase
Express de la palette de composants,
déposez les composants IBX suivants et un composant TDataSource à partir de l'onglet AccèsBD.
Sur la Form1, placez à partir de l'onglet ContrôleDB, un composant DBNavigator et un composant DBGrid.
Faites F12 pour afficher le code de la Form1. Dans la liste des uses, ajoutez Unit2.
Puis F12 pour revenir sur la Form. Mettez les propriétés suivantes :
Dans DataModule1, mettez la propriété Active à True successivement pour IBDatabase, IBTransaction et
IBQuery.
Pour que votre programme puisse ajouter, modifier ou supprimer des données, nous allons transformer la
requête statique ci-dessus en une requête dynamique : déposez sur le Module de données (DataModule),
à partir de l'onglet InterBase Express le composant
IBUpdateSQL
(1) Dans la version Delphi 5 Entreprise, les ordres SQL de IBUpdate peuvent être générés
automatiquement :
► Mettez la propriété Active de IBDatabase1 à True. Faites de même avec IBTransaction1 et IBQuery1.
► Cliquez droit sur IBUpdateSQL1 et activez l'Editeur IBUpdateSQL.
► Cliquez sur Sélectionner les clés primaires, puis sur Générer le SQL. Tous les ordres SQL d'
IBUpdateSQL1 sont alors automatiquement générés.
Compilez, Exécutez :
Nouvelle version d'IB Expert, un outils d'administration pour InterBase : Voir aussi IBaccess
(Gratuit), IBAdmin, IBConsole, DeZign , Universal DBA An
Ce document présente diverses astuces et recommandations afin d'optimiser lesvos performances avec Interbase.
Définissez des index sur tous les champs utilisés dans des tris ou jointures. Les index sont des structures de données
de type " arbre balancé " ou B-Tree qui offrent une nette amélioration en termes de rapidité lors de recherches de
valeurs. Cela est particulièrement utile quand vous triez en fonction d’un champ ou joignez deux tables sur un champ
commun.
Les insertions et modifications de données nécessitent une mise à jour des index, ce qui peut
provoquer une perte de performances lors de ces opérations, mais résulter en gain appréciable lors
des requêtes ultérieures.
Afin de réduire les pertes de performances lors d’un INSERT, prévoyez de désactiver les index
pour les INSERT de données en quantité. Ils ne pourront plus alors accélérer les requêtes, mais ne
seront pas mis à jour par les INSERTions de données. Lorsque l’insertion des données est
terminée, réactivez les index. Ils seront mis à jour et rebalancés en une passe pour toutes les
données insérées.
Reconstruisez régulièrement les index en les désactivant puis les réactivant (ALTER INDEX
nomindex INACTIVE suivi de ALTER INDEX nomindex ACTIVE). Recalculez l’index de
sélectivité (SET STATISTICS INDEX nomindex) si un changement dans la table affecte la
distribution moyenne des valeurs dans les données. Les index sont reconstruits de manière
identique lors d’un restore.
Interbase analysera une requête et l’optimiseur proposera les index qui devront être utilisés pour
accélérer la requête. Mais aucun optimiseur automatique est infaillible. Pour des requêtes
complexes exécutées fréquemment ou manipulant de grandes quantités de données, modélisez
prudemment votre requête. Utilisez l’option SET PLAN avec l’outil ISQL pour tester les requêtes,
constater leurs performances et quel plan de requête choisit l’optimiseur.
Interbase V4.0, V4.1 et V4.2 ont quelque bugs connus, par exemple les requêtes utilisant la
syntaxe JOIN en langage SQL ANSI 92 ne sont pas parsées et optimisées correctement. Evitez
cette syntaxe ou si vous devez l’utiliser, spécifiez votre propre plan de requête.
Interbase maintient son propre cache des pages de données en cours d’utilisation dans la RAM du
serveur. La taille du cache par défaut est de 75 pages pour la V4.0. Avec la V4.2, on passe à 256
pages (qui sont partagées par tous les clients se connectant à la base). Pour une base de données
avec des pages d’un Kilo octets, cela représente seulement 256 Ko. La plupart des serveurs
comportent beaucoup de mémoire, autant l’utiliser ! Tentez de passer le cache de sa valeur par
défault de 256 pages à un nombre de 10000 pages par base. Vous constaterez alors une diminution
des temps de réponse, l’expérimentation vous le confirmera.
BACKUP ET RESTORE
L’emploi du cache disque est quelquefois appelé " entrées/sorties asynchrones " ou " écritures
cachées ". Supprimer le cache et forcer les opérations d’entrées/sorties pour écrire directement sur
le disque est appelé " entrées/sorties synchrones " ou " écritures forcées ". Les I/O asynchrones ont
l’avantage de donner des performances plus hautes, mais la RAM est un support de stockage
volatile et des données peuvent être perdues en cas d’une baisse de tension ou si le serveur plante
ou redémarre sans avoir transféré le cache sur le disque. Les I/O synchrones assurent qu’aucune
donnée ne sera perdue, mais les opérations d’I/O directes sur disque sont plusieurs fois plus lentes
que l’écriture en RAM. Un choix à faire après des tests sur chaque base et dans chaque contexte.
Interbase permet aussi bien les entrées/sorties asynchrones que synchrones. La commande GFIX -
WRITE SYNC MYDATABASE.GDB utilise l’écriture forcée des données (synchrone). La
commande GFIX -WRITE ASYNC MYDATABASE.GDB utilise le cache (asynchrone).
Le service NETBEUI passe en basse priorité sur les serveurs NT, et il y a un moyen dans le
système d’exploitation de monter cette priorité. Certains utilisateurs rapportent avoir obtenu une
performance accrue avec ce moyen.
Référez-vous à votre documentation NT pour savoir comment changer la priorité des services
NETBEUI.
UNIX est plus rapide en multitâche que Windows NT ou NetWare, même avec du matériel
identique, mais cela dépend des versions de chacun de ses OS. Si la rapidité est un critère de
choix, penchez pour un serveur UNIX. Si vous avez du matériel de type Intel, SCO UNIX peut
s’exécuter sur la plupart des plateformes Intel.
Novell NetWare peut être employé comme serveur de fichiers en plus d’un serveur Interbase, mais
dans ce cas, le manager de verrous réseau ne donne pas le premier rôle à Interbase mais au service
des fichiers. Le résultat est que tandis que les utilisateurs lisent et écrivent des fichiers sur la
même machine qui fait tourner Interbase, les performances d’Interbase souffrent d’une
dégradation. La solution est d’installer Interbase sur un serveur dédié, qui ne fasse pas office de
serveur de fichiers. Sur serveur NT, le serveur est configuré par défault pour donner la priorité aux
services de partage de fichiers. Vous pouvez changer cette configuration en passant par :
Sélectionnez " balance ou serveur de bases de données ". Cela peut entraîner un accroissement
important des performances d’Interbase.
PENSEZ AU RAMASSE-MIETTES
Par défaut, Interbase a une fonction intégrée qui nettoie automatiquement les vieilles versions des
enregistrements lorsqu’ils deviennent trop nombreux. L’inconvénient de cette méthode est que si
elle est démarrée par malchance par une transaction cela aboutit à une surcharge de travail pour le
"nettoyage" de la base. Le processus client ralentit durant l’opération. Désactivez le garbage
collector automatique (avec la commande GFIX -h 0) au profit de nettoyages de base programmés
(commande GFIX -s) cela évitera de perturber les performances du client.
Effectuer à bon escient un backup et un restore donne le même résultat qu'un nettoyage complet
de la base. Un backup sauvegarde uniquement la version la plus récente de chaque enregistrement.
Il ne sauvegarde jamais les anciennes versions. Ainsi quand les données sont restaurées, il reste
seulement une version pour chaque enregistrement restauré. Il y a aussi d'autres avantages à
sauvegarder et restaurer régulièrement (cf. plus haut dans ce document).
En parlant du garbage collector, pas mal de programmeurs ne réalisent pas qu'il faut démarrer
(START) et valider (COMMIT) leurs transactions sur une base Interbase. Ouvrir une transaction
prévient d'un nettoyage périodique du ramasse-miettes, les performances se dégradant
progressivement à chaque fois
Modelez votre base en normalisant correctement les données. Les enregistrements qui ont
beaucoup de groupes de champs répétés sont plus larges qu'ils n'en ont besoin. De larges
enregistrements peuvent accroître le coût des tris, et aussi étendre les enregistrements sur plus de
pages que nécessaire, aboutissant sur plus de pages fragmentées, et de gros fichiers disque, le tout
sans aucune utilité.
Concevez votre application de façon à ce qu'elle valide les transactions aussi vite que possible
après les avoir démarrées. Souvent les développeurs démarrent une transaction et ensuite affiche
une interface utilisateur de saisie des données. Obtenez plutôt les données de l'utilisateur dans un
premier temps, et seulement alors démarrez une transaction pour insérer les données et les valider
dans la foulée.
L'objectif est de raccourcir la durée des transactions, réduisant la probabilité que deux applications
concurrentes ne butent sur un enregistrement commun verrouillé. Cela évite aussi beaucoup de
trafic réseau et de ROLLBACKs, puisque c'est votre application qui décide quand soumettre des
données et quand s'en débarasser et non l’utilisateur.
Il est assez facile de comprendre que plus il y a de middlewares, moins les performances sont
bonnes. Donc, on en conclue (et on peut le vérifier souvent) qu’une application Delphi ou C++
Builder qui utilise directement les API de Interbase via sa DLL cliente est plus rapide que son
équivalent utilisant le BDE.