Le contenu de la base de données locale

Dans la base de données locale (sqlite), on va vouloir stocker :

  • L’heure de l’enregistrement dans la DB
  • Les données GPS
    • Heure connue par le GPS
    • Longitude, latitude, vitesse et altitude
    • Heure de la mesure
  • Les données OBD
    • La vitesse, les tours par minute du moteur et le niveau de carburant
    • Heure de la mesure

Ce qui donne le schéma de création suivant :

CREATE TABLE car_status(
	statusdate integer, 
	
	gps_time integer,
	gps_longitude Decimal(9,6), 
	gps_latitude Decimal(9,6), 
	gps_speed decimal(9,2), 
	gps_elevation decimal(9,2), 
	gps_measure_time integer,
	
	obd_speed decimal(9, 2), 
	obd_rpm decimal(9, 2),
	obd_fuellevel decimal(9, 2),  
	obd_measure_time integer,
	
	sent boolean
);

Le contenu de la base de données Salesforce : gros volume de mesure

Dans le projet de l’an passé, on avait stocké les informations venant de Salesforce dans des ‘Custom Object’. Cela allait car on ne stockait pas souvent les informations (seulement quelques fois par heure). Maintenant on va pouvoir stocker des données plusieurs fois par minute.

Dans Salesforce, les Custom Objects ne sont pas adapté pour cela (ils coutent cher en espace de stockage pour le système).

Pour cela SF propose les Big Objects, qui peuvent gérer par défaut jusqu’à un million d’enregistrement, mais on peut avoir des configurations qui gèrent jusqu’à un milliard d’enregistrements !

Pour l’insertion et la lecture de données, les Big Objects se manipulent presque de la même manière avec deux contraintes :

  • On ne relie pas un Big Object à un autre ou à un Custom Object : c’est juste une grosse liste. Ce qui veut dire que le code du projet de l’an passé ne pourra pas fonctionner de la même manière
  • Je chemin pour faire les requêtes est moins flexible, on doit pré-câbler l’ordre des critères de requête pour que cela soit performant.

La création d’un Big Object se fait dans le menu Big Object du setup :

On voit ici que le chemin pour lire les données passe :

  • D’abord en demandant le numéro du tracker, Tracker_ID__c ; c’est l’identifiant qu’on va donner à chaque appareil Raspberry Car, pour ne pas mélanger les données venant de plusieurs voitures
  • Puis la date de capture de la donnée, Requested_On__c, en ordre décroissant (en partant de la plus récente, pour que cela aille plus vite pour lire les dernières mesure)