| |
 |
D. Richard Hipp
Développeur
Hipp, Wyrick & Company, Inc |
|
Richard Hipp
"SQLite a été conçu pour remplacer fopen(), pas Oracle"
En proposant une solution Open Source à un problème personnel, D. Richard Hipp a aidé les développeurs à se libérer des contraintes du schéma client/serveur, tout en conservant l'utilité de SQL. SQLite est aujourd'hui intégré à PHP5.
24/05/2006 |
| |
 |
 |
JDN
Développeurs. Quelles étaient vos motivations premières pour écrire SQLite ?
D. Richard Hipp A l'origine, j'ai écrit SQLite 1.0 pour remplacer Informix (ndlr : base de données IBM) au sein d'une application requérant une haute disponibilité avec un minimum d'assistance technique. Informix marchait très bien quand cette application était lancée, mais parfois, après avoir relancé la machine, celui-ci ne voulait pas se relancer. Cela empêchait mon application de fonctionner. Et étant donné que cette application était tout ce que voyait le client - Informix se cachait en tâche de fond anonyme -, c'était elle qu'on accusait, et donc moi.
En écrivant SQLite pour accéder directement aux fichiers, et non par communication avec un serveur, je m'assurai que mon application marcherait même quand les autres services de la machine auraient un problème.
Y a-t-il plus d'avantages à stocker ses données dans des fichiers que de se libérer du serveur ?
Une architecture client/serveur est plus capable de supporter la charge de larges problèmes, que si l'on travaille directement avec des fichiers.
Cela étant, la conception client/serveur requiert plus de travail d'administration : configurer le serveur, s'assurer qu'il tourne, fournir les bons mots de passe à tous les clients, etc. Celle-ci requiert également un plus grand espace mémoire, ce qui la rend inadapté aux applications pour systèmes embarqués. Enfin, les systèmes client/serveur ont plus à faire pour atteindre de bonnes performances, étant donné qu'ils ont un surcoût d'IPC (Inter-Process Communication, communications inter processus) et d'échanges de contexte, que n'a pas l'approche direct-to-disk de SQLite.
Selon vous, quels sont les scénarios où SQLite est le plus adéquat, et ceux où il est préférable d'utiliser un base de données serveur ?
Pour simplifier, SQLite a été conçu pour remplacer fopen(), pas Oracle (ndlr : fopen() est une fonction C standard d'ouverture d'un accès à un fichier).
Il faut utiliser SQLite pour remplacer les accès directs à des fichiers, et les solutions internes de stockage. Pour ces scénarios, SQLite vous donne un stockage portable, autodescriptif, transactionnel et sûr, et vous épargne beaucoup de temps et d'efforts.
SQLite est également approprié quand il s'agit de remplacer une base client/serveur pendant le développement et les tests, ou pour des démonstrations, là où installer une vraie base client/serveur serait trop compliquée. Enfin, SQLite est tout à fait approprié pour les usages sur systèmes embarqués, limités par la mémoire et la puissance du processeur.
En pratique, on découvre que nombre d'applications utilisant traditionnellement une base client/serveur, n'ont pas besoin de la haute disponibilité offerte par un serveur, et que SQLite les remplace tout aussi bien. En d'autres termes, la plupart des applications n'ont pas besoin d'autant de disponibilité que leurs développeurs ne veulent le croire.
Généralement, SQLite sera plus rapide qu'une base client/serveur, pour peu que les besoins en disponibilité ne soient pas excessifs.
|
|
 Personne n'est autorisé à contribuer tant que je n'ai pas son contrat entre les mains." |
|
Bien que SQLite est aujourd'hui dans le domaine public, vous maintenez un ferme contrôle sur son évolution. Cela ne va-t-il pas contre la raison d'être du domaine public ?
SQLite est utilisé au sein de produits largement distribués. Les avocats des éditeurs de ces produits insistent sur la bonne définition de la non-appartenance du code. Ils ne veulent pas devoir rappeler des millions de produits, ou payer des millions de dollars en frais de licences si un provocateur surgit un an plus tard en clamant avoir des droits sur une partie du code SQLite. Pour cela, je conserve les "contrats" signés de chaque contributeur au code SQLite dans un coffre de mon bureau. Personne n'est autorisé à contribuer du code tant que je n'ai pas son contrat entre les mains. Ces contrats me sont nécessaires pour m'assurer que SQLite reste dans le domaine public. Mais ils découragent également les contributeurs.
Je demande également un niveau très élevé pour le code source de SQLite. De nombreuses sociétés qui l'utilisent me payent pour faire en sorte que le code reste sûr et propre. Ces contraintes réduisent d'autant plus le nombre de contributeurs potentiels.
SQLite fait maintenant partie de PHP5, ainsi que de Mac OS X. Cela a-t-il changé votre manière de gérer le projet ?
Les intégrations à PHP5 et Max OS X n'ont rien changé, si l'on excepte l'augmentation de ma facture de bande passante lors de l'annonce pour PHP5. Le grand changement est survenu quand SQLite a commencé à être très utilisé sur les systèmes embarqués, le plus souvent par des sociétés qui ne reconnaissent pas publiquement l'utiliser. Ce sont les mêmes sociétés qui insistent pour que je conserve les contrats légaux des contributeurs.
Cela a-t-il apporté de nouvelles difficultés, ou de nouveaux besoins ?
L'implémentation est assurément devenue plus complexe au fur et à mesure de l'ajout de fonctionnalités, mais globalement, je pense que cette complexité est parfaitement gérable.
J'ajoute de temps à autres les fonctionnalités demandées par mes clients, mais je ne change jamais la manière dont fonctionne l'interface. Je travaille dur pour faire en sorte que l'API SQLite et le format du fichier soient toujours compatibles avec les versions précédentes.
SQLite est donc très prisé sur les systèmes embarqués. Qu'en est-il de la complétude du support SQL sur ces environnements ?
SQLite implémente environ 99% du SQL utilisé le plus souvent par les développeurs. Plusieurs fonctionnalités ésotériques sont oubliées, pour maîtriser à la fois la taille et la complexité du code. Mais je pense que les gens s'en tirent tout aussi bien sans ces aspects obscurs.
|
|
Le code source de SQLite est avant tout écrit en Tcl." |
|
Quels sont les langages, outils et méthodes que vous utilisez pour développer SQLite ?
Environ 60% du code écrit pour SQLite existe seulement pour raison de test. Ce code est bien sûr mis de côté lors de la compilation finale de la bibliothèque, bien sûr. Le plus gros de ce code de test est écrit en Tcl. Ainsi, alors que la plupart des gens disent que SQLite est écrit en C parce que l'interface est conçue pour ce langage, j'aime à dire qu'il est implémenté en Tcl, vu que la suite de test est en vérité la partie du code la plus grosse et le plus importante. De manière générale, je réalise la plupart de mes développements en Tcl/Tk, avec une pincée de code C ici ou là.
Pour ce qui est de mon environnement de travail, j'utilise actuellement SuSE 9.2, un éditeur de texte basique écrit en Tcl/Tk avec des réglages pour imiter Emacs, et gcc, gdb, gprof et valgrind. J'utilise mingw configuré en compilateur multiplate-forme pour produire les exécutables Windows.
La plupart des autres bases de données visent la vitesse ou la complétude SQL, tandis que vous semblez viser la petite taille. Qu'est-ce qui vous donne le plus de travail, et quelles sont vos priorités ?
Mes priorités pour SQLite sont la robustesse, l'administration simple, la faible occupation-mémoire, la vitesse et les fonctionnalités, dans cet ordre. L'objectif premier est de faire un moteur de base de données qui fonctionne du premier coup ("a database engine that "just works"").
Les fonctionnalités qui pourraient apparaître dans les prochaines versions sont la recherche full-text, et la possibilité de réaliser des lectures et écritures incrémentales sur les BLOBs.
Avant de concevoir SQLite, utilisiez-vous plutôt un stockage par fichier, ou des bases de données serveur ?
Les deux : j'utilisais des bases serveur quand j'avais besoin de SQL, et les fichiers quand j'avais besoin d'une administration simple et une haute disponibilité. J'ai écrit SQLite pour avoir les deux à la fois. |
| |
Propos recueillis par Xavier Borderie, JDN Développeurs |
|
|
PARCOURS
|
|
 |
| |
Richard Hipp, 45 ans, est fondateur et principal développeur chez Hipp, Wyrick & Company, Inc (Hwaci).
1992 Fondation de Hwaci.
|
|
|
|
Dossier 
