2.3.3.2. MySQL, un système de gestion de bases de données open-source.

De nombreux logiciels sont spécialisés dans la gestion des bases de données relationnelles. Les historiens, et plus généralement les chercheurs en sciences humaines et sociales, privilégient souvent les logiciels les plus simples d’utilisation, intégrant le Système de gestion de base de données (SGBD) à une interface graphique facilitant la conception et la saisie, à l’image de FileMaker ou d’Access qui sont utilisés dans la plupart des cours d’initiation à l’emploi des bases de données de ces disciplines. Ces logiciels ont cependant les inconvénients d’imposer des limites à la conception, d’être peu efficaces sur un très grand nombre de données et de n’intégrer que faiblement les normes internationales définies dans le domaine des bases de données, en particulier la norme SQL de 1992 (SQL signifiant Structured Query Language). Cela pose non seulement des problèmes quant à la pérennité des bases conçues avec ces logiciels, mais empêche également d’employer le langage SQL qui permet d’exécuter facilement des requêtes complexes et performantes pour interroger la base de données.

Mon ambition étant de concevoir une structure qui pourrait éventuellement être utilisée pour des études ultérieures ou partiellement mise à disposition sur Internet, je me suis orienté vers des systèmes plus « solides » où le SGBD est indépendant de l’interface graphique de saisie¹³¹. Mon choix s’est fixé sur MySQL¹³², un SGBD open-source qui présentait les avantages d’être gratuit, soutenu par une très large communauté d’utilisateurs – garantie d’une résolution simple et rapide des problèmes – et très proche de la norme SQL dans ses versions récentes¹³³.

Cette proximité a d’ailleurs permis de résoudre un problème lié à la gestion de la variable temporelle que je n’avais pas identifié lors de la conception théorique de la base de données et qui n’influa donc pas dans la décision d’adopter MySQL. Dans les logiciels habituellement utilisés en histoire, il reste en effet impossible de saisir dans un attribut de type Date une valeur imprécise ne comprenant pas le jour ou le mois. Le problème peut être contourné par l’utilisation d’attribut de type Entier, mais cette solution n’est ni élégante, ni facile puisqu’elle oblige à développer des fonctions particulières pour gérer la variable temporelle ainsi codée. Au contraire, le type Date de la norme SQL accepte sans problème des valeurs imprécises, comme par exemple ‘1974-03-00’ pour le mois de mars 1974, sans précision de jour. Les attributs de type Date peuvent ensuite être interrogés et manipulés avec un véritable arsenal de fonctions spécifiques. Si cet avantage ne changeait que peu de choses dans la gestion générale de la variable temporelle basée sur l’année comme unité, il s’avéra crucial pour distinguer efficacement des éditions ou des tirages différents mais effectués la même année¹³⁴.