Dans une base de données quelconque qui restera anonyme [1] un mien collègue a déniché qu’un mariage pouvait avoir une date de fin future planifiée (nous ne parlons pas des divorces passés ou proches).
En l’occurrence, tous les mariages étaient censés se dissoudre le 31 décembre 9999. C’est évidemment stupide. Cette donnée aberrante est l’équivalent en date d’un nombre magique : une telle donnée possède un autre sens que sa simple valeur, en l’occurrence le fait que la date de fin de mariage n’existe pas, le mariage n’a pas été dissous.
Cela peut-il poser un problème réel dans le futur ? Je concède que la perspective est lointaine, mais il n’y a pas qu’un programme concerné par ce genre de phénomène, loin de là.
Il n’est pas complètement impossible que, grâce aux progrès de la médecine, du voyage dans le temps, de la cryogénisation, ou de la numérisation des cerveaux, certains d’entre nous voient l’an 9999 [2]. Il est encore plus improbable, mais pas impossible non plus, que les données de cette application aient été conservées [3], pour une raison ou une autre, jusqu’à cette époque reculée, pour payer une aide sociale ou une pension quelconque (de la part de quel État, caisse et en quelle monnaie ?). Au passage, il ne devrait rester aucun couple n’ayant pas divorcé (1% de taux de divorce annuel pendant 8000 ans multiplié par 4 milliards de couples = plus aucun couple du XXIè siècle encore marié en 9999), ce qui résoudra le problème par le vide.
Bref, nous nageons dans la pure spéculation, mais il reste une morale : cette application est mal programmée, elle ne distingue pas ce que toute base de données devrait connaître depuis plusieurs décennies, à savoir la distinction entre une donnée et une donne absente, ce qu’en langage de base de données on nomme NULL
[4].
Au passage : Saint E. F. Codd aurait même voulu distinguer valeur existante inconnue et valeur sans signification, c’est-à-dire « Non renseigné » et « Non applicable ».
Exemple : dans un logiciel administratif, la date de naissance peut être « Non renseignée », mais on sait qu’il y en a forcément une [5] ; par contre le champ « Nom marital » vaudra « Non applicable » pour tous les gens non mariés ou qui ont déclaré ne pas en utiliser — mais il pourrait être « Non renseigné » si on sait que Mlle Dupont a changé de nom en se mariant.
Les développeurs informatiques ne sont parfois même pas fichus de gérer correctement le cas du NULL
. Il a quelques propriétés surprenantes dont il faut tenir compte, comme 1 + NULL
= NULL
, ou comme la clause IF NULL = NULL
qui renverra toujours « faux ». Noter que selon les bases de données, une chaîne vide est équivalente à un NULL
(Oracle) ou pas (SQL Server, PostgreSQL...). Pour ne pas embrouiller plus les choses, le N/A
a donc finalement été laissé de côté. Et, mine de rien, mes collègues et moi sommes obligés de le réintroduire de manière plus fastidieuse et visible dans les bases de données décisionnelles que nous sommes payés pour créer. Signalons également le cas pathologique de SAP R/3, qui n’utilise pas les NULL
même s’il les connaît, et préfère INITIAL
, matérialisé en pratique par un espace solitaire !
Pour revenir aux dates : j’ai rencontré tout récemment une autre application qui stockait des valeurs magiques : 1erjanvier 1900 (admettons, cette date ne reviendra pas), et 1erjanvier 2050. Une date pareille est une erreur, il y a une chance non négligeable que les données soient encore utilisées à cette date, même si le responsable de ce choix sera probablement à la retraite [6].
Dans un registre similaire, un nombre peut aussi être infini, c’est même standardisé, mais le support par certaines bases de données est bancal.... On dérive vers l’ontologie, puisque l’infini n’est pas de ce monde : une base de données le reflétant doit-elle pouvoir le contenir ?
Notes
[1] Parce que 1) je ne m’en souviens pas précisément, ce billet fut entamé il y a bien des mois ; 2) c’est sans doute une base d’un client ; et 3) ça n’a pas d’importance tant le problème est courant.
[2] En cas de cryogénisation, la blague dit que tous les programmeurs COBOL seront réveillés un peu avant cette date pour un remake du bug de l’an 2000.
[3] En fait, la NSA en aura probablement une copie jusqu’à la fin des temps.
[4] J'ai au passage une pensée (haineuse) envers les traducteurs de BusinessObjects qui ont traduit “Is not null” par « N’est pas nul » (soit : « n’est pas zéro »), un véritable contresens qui me coûte un quart d’heure d’explication à chaque formation que je donne. Si encore c’était la seule abomination linguistique du produit...
[5] Le cas de certaines divinités est négligé.
[6] Quoique par les temps qui courent, ça n’est même plus sûr.
2 réactions
1 De Benoit - 18/11/2013, 14:27
Bonjour,
Moi qui travaille aussi dans le décionnel avec BO et ODI et qui doit travailler avec plein de base où les données sont historisées avec des dates de début et des dates de fin, on redresse, en général, toutes les dates de fin positionnées à null par 31/12/9999. Comme cela, nous pouvons utiliser le between. D'un point de vue théorique c'est en effet pas super, mais bon dans la pratique y'a photo.
2 De Voyageur - 17/02/2014, 21:32
Je me remets tout de suite au travail pour reconstruire ma machine... Je suis impatient de voir ce qu'il va se passer le 31/12/9999. J'espère que ça sera mieux que le" bug" de l'an 2000.