IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PHP & Base de données Discussion :

Comment bien penser à ma nouvelle base de donnée [MySQL]


Sujet :

PHP & Base de données

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre expérimenté
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    3 167
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2005
    Messages : 3 167
    Par défaut Comment bien penser à ma nouvelle base de donnée
    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
    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

    Nom : mysql-join.jpg
Affichages : 164
Taille : 232,7 Ko

    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

  2. #2
    Membre Expert

    Profil pro
    Inscrit en
    Mai 2008
    Messages
    1 576
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2008
    Messages : 1 576
    Par défaut
    - 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.

  3. #3
    Membre expérimenté
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    3 167
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2005
    Messages : 3 167
    Par défaut
    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?

  4. #4
    Membre expérimenté
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    3 167
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2005
    Messages : 3 167
    Par défaut
    Mais est-ce que ca faut vraiment la peine de faire la table sensors pour 4 champs???

  5. #5
    Membre Expert

    Profil pro
    Inscrit en
    Mai 2008
    Messages
    1 576
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2008
    Messages : 1 576
    Par défaut
    Citation Envoyé par pierrot10 Voir le message
    É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.

    Citation Envoyé par pierrot10 Voir le message
    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.

  6. #6
    Membre expérimenté
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    3 167
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2005
    Messages : 3 167
    Par défaut
    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....

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 2
    Dernier message: 01/02/2008, 16h00
  2. [ ouverture d'une nouvelle base de données]
    Par CHRISTOPHE SANOU dans le forum Access
    Réponses: 1
    Dernier message: 29/03/2006, 15h48
  3. Comment arbitrer le choix Une base de donnée ou deux ?
    Par medstat2 dans le forum Décisions SGBD
    Réponses: 1
    Dernier message: 28/03/2006, 16h42
  4. ouverture d'une nouvelle base de données
    Par CHRISTOPHE SANOU dans le forum Access
    Réponses: 1
    Dernier message: 28/03/2006, 13h34
  5. [SQLite] Cherche le nom de la nouvelle base de données gérée par PHP5
    Par Thierry8 dans le forum PHP & Base de données
    Réponses: 2
    Dernier message: 15/02/2006, 20h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo