Soit ! Il s'agit donc d'une combinaison d'informations et effectivement dans notre propos de ce jour, nous combinerons dates et heures. 

 

Etymologiquement timestamp renvoie au coup de tampon du facteur affranchissant le courrier, et vous verrez qu'effectivement les timestamps nous rapprochent du bonheur simple incarné par Jacques Tati dans "Jour de Fête !" Ce coup de tampon matérialisait, et matérialise encore, la date et l'heure d'envoi de la lettre, accompagnés le plus souvent du lieu du bureau de poste d'origine. Ne pensez surtout pas que cette notion d'oblitération est désuète, car n'oubliez pas que "le cachet de la poste faisant foi" et pour s'en convaincre il suffit de se rendre à la poste du Louvre (la seule de Paris ouverte jusqu'à minuit) le soir fatidique d'expiration du délai de paiement du tier provisionnel ...

 

La vedette du jour est donc le timestamp ! L'idée est de pouvoir marquer des enregistrements avec la date et l'heure de dernière modification par exemple. Ok, il n'y a rien de compliqué pour réaliser ce marquage, vous allez me dire ! En effet il suffit de renseigner dans l'enregistrement deux champs : un champ date et un champ heure, comme sur le bon vieux cachet du facteur à cheval sur le timbre (le cachet, pas le facteur...)

Cette solution est retenue par nombre de développeurs et a l'avantage d'être extrêmement simple à mettre en œuvre. Généralement les deux champs sont renseignés dans le trigger de sauvegarde de la table et le tour est joué. 

 

Devant une telle simplicité, pourquoi chercher plus loin et chercher à utiliser un timestamp ? Avant de donner mon argumentation, car j'en ai bien une, je désire au préalable faire le point sur ces deux champs. 

 

Tout d'abord intéressons-nous à l'empreinte laissée par ces deux champs dans le fichier de données. Un champ date pèse 8 octets dans le fichier de données de 4D v11 SQL (seulement 6 dans les versions précédentes). Un champ heure pèse 8 octets également (4 dans les versions précédentes). A cela il faut ajouter 8 octets par champ au titre de la micro-structure (objet présent dans chaque enregistrement et indispensable à 4D pour gérer les données ; 4 octets dans les versions précédentes). Le poids total de l'oblitération est donc de 8 + 8 + 8 + 8 = 32 octets ( 6 + 4 + 4 + 4 = 18 octets dans les versions précédentes).

 

 

Regardons à présent du côté des traitements. 

Si votre oblitération à deux champs sert à organiser, par exemple, une file d'attente de patients (premiers arrivés, premiers reçus en consultation) alors vous allez devoir faire un tri sur deux champs tel que :

Supposons que cette file d'attente comporte un nombre important d'enregistrements. Dans ce cas vous serez tenté d'indexer un des champs, voire les deux, pour accélérer le traitement. Or cet index ne servira à rien car un tri sur deux champs est toujours séquentiel comme nous le rappelle la documentation de 4D. Bien sûr les utilisateurs de la version 11 peuvent ajouter un index composite. Celui-ci coûtera au minimum 70 octets par clef, c'est-à-dire par enregistrement car il sera de type B-Tree et non Cluster.

 

A présent, nous devons faire une recherche pour les visites de la semaine entre lundi matin 8h30 et vendredi 17h00. La recherche est assez simple ; il s'agit d'une recherche en fourchette sur deux couples de champs soit :