Discussion :

[kaari kosaku]

Bonjour,

Je développe un back-end pour une application de visualisation automate, et j'ai des difficultés pour la conception de ma base de donnée (sous MySQL).


Situation

J'importe depuis le réseau les valeurs des variables automates que je souhaite archiver dans ma base de donnée. Le but étant de dater les enregistrements, pour proposer des courbes d'évolution des températures/pressions/entrées logiques en fonction du temps.

Depuis le back-end, l'utilisateur sélectionne les variables automates qu'il souhaite récupérer, il peut alors en ajouter certaines comme étant des variables dont il souhaite conserver l'évolution en fonction du temps (on va les appeler les variables archivées).


Solution ?

Table <Variable_PLC> :

• <<PK>>Id : int
• AdressePLC : text (NN - IU)
• Nom : text
• Type : text

Table <Archive>

• <<PK>>TspEnregistrement : timestamp
• Id1 : Type1
• Id2 : Type2
• ....

//Id1 et Id2 étant les Identifiants des variables que j'enregistre et Type1, Type2 leur type : int, float, text....


En gros je souhaiterais créer une table dont les noms des colonnes et leurs types soient des "clefs étrangère", ou plus exactement des résultats de requêtes, avec bien entendus des vues et des requêtes dynamiques qui vont bien pour que je puisse accéder grâce à des commandes simples à ces données.


D'après vous, est-ce la bonne solution ? Apparemment du SQL dynamique me permettrait d'arriver au fonctionnement voulu mais je n'ai aucune idée de comment je pourrais le mettre en place.

Si je souhaite aussi sauvegarder la dernière valeur de toutes les variables qui ne sont pas archivées, quelle serait la méthode appropriée puisqu'elles sont toutes de type différents.
J'avais pensé créer une table par type de variable (une table float, une table int, une table text) pour ranger les valeurs de mes variables, mais j'ai abandonner cette idée car pour aller chercher mes valeurs ils aurait fallu que j'explore toutes les tables pour trouver la bonne, et cela aurait créé un nombre de requête exponentiel en fonction du nombre de table.


Merci d'avance pour toute remarque ou proposition que vous pourriez me transmettre .

[SQLpro]

Votre modèle sera une catastrophe en terme :

• de volume
• d'accès concurrent
• de performances de requête.

Lisez les article que j'ai écrit, notamment sur la méta modélisation.
Au pire utilisez du XML si votre SGBD le supporte avec une indexation efficace (par exemple si c'est pour MS SQL Server).

A +

[kaari kosaku]

Votre modèle sera une catastrophe en terme :

• de volume
• d'accès concurrent
• de performances de requête.

Lisez les article que j'ai écrit, notamment sur la méta modélisation.
Au pire utilisez du XML si votre SGBD le supporte avec une indexation efficace (par exemple si c'est pour MS SQL Server).

A +

Merci pour votre réponse.

Initialement, j'avais prévu de stocker ces informations en XML, étant donné que le script php qui se charge de les sélectionner est appelé par un XmlHTTPRequest Javascript. Le problème étant que le nombre important d'enregistrements et l'absence d'indexation dans un fichier XML sont désastreux en terme de performances.

J'ai lu certains de vos articles et en particulier celui sur les méta-données. J'avais pensé à quelque chose de similaire, mais j'avais peur de 2 choses :

Premièrement, que l'utilisation du CAST ne corrompe mes float, sur ce point, j'avais tort car on peut choisir le degré de précision que l'on souhaite conserver lors de la conversion (http://i.msdn.microsoft.com/dynimg/IC45981.gif)
Deuxièmement, le poids de la table, car une chaine de caractère prends plus de place qu'un int, un float, ou un booléen.

Je suis loin d'être un expert dans le domaine (c'est pour ça que je demande de l'aide et que j'essaie d'expliquer mon raisonnement ), et j'aimerais vous demander votre expertise.
Pensez-vous que pour l'utilisation que je compte faire de cette table, c-à-d enregistrements réguliers de données ( par ex. toutes les 5secondes, 20 nouvelles entrées <=> 10.000.000 d'enregistrements (pour un mois d'archivage de données)), votre méthode sur les méta-données soit appropriée en terme de performance et de taille de table ?


Sinon, j'avais pensé à une structure de tables similaire, mais en créant une table par type de donnée (float, int, bool et varchar), le problème qui s'est posé a été l'accès à la table en fonction du type de donnée qu'on souhaite enregistrer, et j'ai trouvé cette technique horrible en terme de structure de données et et dynamicité.

Je vais essayer d'adapter votre méthode sur les métas-données et proposer un schéma adapté à mon utilisation.

Merci de vos conseils.

[SQLpro]

Merci pour votre réponse.

Initialement, j'avais prévu de stocker ces informations en XML, étant donné que le script php qui se charge de les sélectionner est appelé par un XmlHTTPRequest Javascript. Le problème étant que le nombre important d'enregistrements et l'absence d'indexation dans un fichier XML sont désastreux en terme de performances.

Le XML étant indexable dans MS SQL Server, vous obtiendrez de bonne performances. Le but étant non pas de traiter cela en PHP, ce serait catastrophique, mais des faire des requêtes SQL incorporant XQuery et XPath. Voir de créer des vues exposant les principaux éléments XML qui vous intéressent.

J'ai lu certains de vos articles et en particulier celui sur les méta-données. J'avais pensé à quelque chose de similaire, mais j'avais peur de 2 choses :

Premièrement, que l'utilisation du CAST ne corrompe mes float, sur ce point, j'avais tort car on peut choisir le degré de précision que l'on souhaite conserver lors de la conversion (http://i.msdn.microsoft.com/dynimg/IC45981.gif)

Rien ne vous empêche de créer plusieurs tables de métadonnées, une par type. L'indexation y sera nettement meilleure. Par exemple une pour les chaines, l'autre pour les nombre, la troisième pour les dates...

Deuxièmement, le poids de la table, car une chaine de caractère prends plus de place qu'un int, un float, ou un booléen.

Je suis loin d'être un expert dans le domaine (c'est pour ça que je demande de l'aide et que j'essaie d'expliquer mon raisonnement ), et j'aimerais vous demander votre expertise.
Pensez-vous que pour l'utilisation que je compte faire de cette table, c-à-d enregistrements réguliers de données ( par ex. toutes les 5secondes, 20 nouvelles entrées <=> 10.000.000 d'enregistrements (pour un mois d'archivage de données)), votre méthode sur les méta-données soit appropriée en terme de performance et de taille de table ?

Il faudra certainement à terme partitionner, et voir s'il est possible de faire des partitions de type Read Only

Sinon, j'avais pensé à une structure de tables similaire, mais en créant une table par type de donnée (float, int, bool et varchar), le problème qui s'est posé a été l'accès à la table en fonction du type de donnée qu'on souhaite enregistrer, et j'ai trouvé cette technique horrible en terme de structure de données et et dynamicité.

C'est la meilleure voie et il faudrait y ajouter l'héritage et une vue de typage

Je vais essayer d'adapter votre méthode sur les métas-données et proposer un schéma adapté à mon utilisation.

Merci de vos conseils.

A +

[kaari kosaku]

Voici la représentation UML de mes tables :


et la vue associée

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE VIEW Vue_Archive
AS
SELECT TypeBool.Id, TspCapture, Valeur AS ValeurBool, NULL AS ValeurFloat, NULL AS ValeurInt,
FROM TypeBool INNER JOIN Archive ON TypeBool.Id = Archive.Id
UNION ALL
SELECT TypeFloat.Id, TspCapture, NULL AS ValeurBool, Valeur AS ValeurFloat, NULL AS ValeurInt,
FROM TypeFloat INNER JOIN Archive ON TypeFloat.Id = Archive.Id
UNION ALL
SELECT TypeInt.Id, TspCapture, NULL AS ValeurBool, NULL AS ValeurFloat, Valeur AS ValeurInt,
FROM TypeInt INNER JOIN Archive ON TypeInt.Id = Archive.Id

Cela vous parait-il envisageable ?

En revanche je ne vois pas comment je pourrais procéder pour l'insertion des données (base mysql), à moins de passer par une procédure.