Discussion :

[pierrot10]

Bonjour,

Je me replonge dans MySQL et PHP et je dois créer une base de donnée qui contrindra pas mal de donnée.

J'hésite à utiliser des jointures. Donc, créer 3 tables donc la deuxième aura l'id de la premiere.
Ou j'ai je crée une table et les informations seront enregistre coup par coup.

Ce que fais mon application. Je mesure des données via des capteurs et LoRaWAN. Ces infos me sont retrounées (JSON) sur mon serveur. Je les traite et les enregistrent dans MySQL.

Voici concretement les données:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
{
	"app_id":"lora",
	"dev_id":"featherwings",
	"hardware_serial":"98TTTTTTTTTT0000",
	"port":1,
	"counter":34,
	"payload_raw":"Mzg4LDIzLCwsNDgsODAABBAABBAABBAA==",
	"payload_fields":{"al":"","ba":"388","da":"","hu":"48","la":"","lo":"","lu":"16","mo":"807","pr":"","te":"23","uv":""},
	"metadata":
	{
		"time":"2017-10-04T19:49:20.310914635Z",
		"frequency":868.5,
		"modulation":"LORA",
		"data_rate":"SF7BW125",
		"coding_rate":"4/5",
		"gateways":
		[
			{
				"gtw_id":"exx-b827xxxxxxxxxxxx",
				"timestamp":3767303051,
				"time":"2017-10-04T19:49:20.25902Z",
				"channel":2,
				"rssi":-51,
				"snr":7,
				"rf_chain":1,
				"latitude":44.21944,
				"longitude":5.14136,
				"altitude":40
			}
		]
	},
	"downlink_url":"https://something.thethingsnetwork.org/ttn-eu/api/v2/down/lora/featherwings?key=something"
}

Je pense donc créer une tables tb_measures avec les champs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
app_id
dev_id
hardware_serial
port
counter
payload_raw

et rajouter les champs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
al
ba
te
lu
etc

pour enregistrer les valeurs de 'payload_fields'

idem pour 'gateway'

J'hésite de créer une table tb_payload ou j'insérai les valeur de 'payload_field' avec une jointure sur tb_measure.
Idem pour 'gateway', un peu comme ceci



Je me pose la question ce que vous feriez? Utiliseriez-vous une jointure ou feriez-vous tous dans la meme table avec un grand nombres de champs pour chaque valeur.

Par la suite, je vais devoir extraire les informations de 'payload_fields' pour faire un chart. Je n'ai pas variement besoin des autres informations, mais je pense que c'est bien de les avoir enregistrés de toute manière.

Merci pour votre point de vu

[Tsilefy]

- Si on n'a pas besoin de faire une recherche dans payload_fields ou gateways mais juste les lire, et si on ne les lit pas indépendamment mais toujours avec le reste de tb_measures, je les stockerais dans la table, dans un champ de type JSONB.

- Sinon oui, une jointure est parfaite pour ça. Ça permet de normaliser tes données et avec des index appropriés tu n'auras pas de problèmes de performance.

[pierrot10]

Hello
En soit , les informations sur la table gateway, ne sont que les informations sur la gateway, par laquelle les mesures ont été envoyée. Il n'y aura pas de cherche spécifiques dans cette table. Étant donné que beaucoup de mesures peuvent être envoyées par la meme gateway, je pensais faire une table pour les gateway. Mais ca m compliquerai mes requêtes. Quoi ça serait plus simple de mettre les info sur les gateway dans ma table mesures. N'est-ce pas?

Par contre , les mesures seront affichée sur une pages web sous la forme d'un graph. Il n'y aura pas de moteur de recherche, pour le moment, Mais c'est à prévoir.

Ça serait donc mieux de faire deux tables.
Ma table principal: measures, et ma table jointe: sensors.

Est-ce bien?

[pierrot10]

Mais est-ce que ca faut vraiment la peine de faire la table sensors pour 4 champs???

[Tsilefy]

Étant donné que beaucoup de mesures peuvent être envoyées par la meme gateway, je pensais faire une table pour les gateway.

Si c'est le cas, tu dois séparer gateway et mesures et utiliser une clé étrangère représentant le gateway dans ta table de mesures plutôt que de les écrire à chaque nouvelle entrée. Mais ça t'oblige à vérifier à chaque fois si le gateway existe déjà dans la base ou pas. Après ce n'est pas compliqué à faire.

Mais est-ce que ca faut vraiment la peine de faire la table sensors pour 4 champs???

Oui. Dans le doute, je normalise toujours en séparant les données. C'est plus facile de faire des jointures que de modifier une table dénormalisée avec des données dedans: bon courage pour tout séparer plus tard si tu découvres que finalement tu dois déplacer des données dans d'autres tables, soit pour des raisons de performance, soit des raisons de facilité d'utilisation.

Ce qui m'emmène à la question importante: quel type de projet est-ce? Un simple projet hobby avec une quantité limitée de données, ou un projet pro avec de grosses quantités de données? Si c'est le premier (et que ton but est de finir ton application elle-même, pas de perdre du temps sur la base de données), mets tout dans une seule table. Si c'est le second, sépare tes données en 3 tables, lie les avec des clés étrangères et utilise des jointures.

[pierrot10]

Hello

merci pour ta réponse.
Donc l'image que j'ai mise dans mon premier post, est bonne alors? Je vais donc séparer mes données (sensors, measures, gateway)

Pour le moment, c'est un projet perso, mais je compte le proposeer à des cultivateurs. Il mesures l'état de la terre, humidité, etc....

[pierrot10]

Mais ça t'oblige à vérifier à chaque fois si le gateway existe déjà dans la base ou pas

Je pourrais aussi faire un UPDATE. Si elle existe, elle la met à jour, si non elle crée. Un update crée une entrée si elle existe pas, n'est-ce pas?

Code PHP :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
$sql_update = '
		UPDATE tb_gateways SET 
			gtw_id = "'.$gtw_id.'",
			timestamp = "'.$timestamp.'",
			time = "'.$time.'",
			channel = "'.$channel.'",
			rssi = "'.$rssi.'",
			snr = "'.$snr.'",
			rf_chain = "'.$rf_chain.'"
 
 
		WHERE gtw_id = '.$gtw_id;
 
mysql_query($sql_update) or die('Error SQL !'.$sql_update.'<br>'.mysql_error());
$gateway_id = mysql_insert_id();

[Tsilefy]

Oui, ton schema est bon, et oui un update est exactement ce que je voulais dire.

[grunk]

Si tes données sont de "simple" valeur de capteur qui arrive toutes les X secondes , une base mysql n'est peut être pas la meilleur des solutions.

J'ai déjà jouer avec InfluxDB qui est dédié à ce genre d'exercice. C'est extrêmement performant pour stocker des séries temporelle et les exploiter; En revanche ca ne sais faire que ça et il faut souvent garder une base relationnelle en plus à coté.

Si tu as potentiellement beaucoup de mesure à stocker (plusieurs millions) ca peut être une option intéressante.

[pierrot10]

Salut Grunk,

Merci pour cette info, je vais voir!