Discussion :

[Firlfire]

Bonjour,

Je dois mettre en place un système d'inventaire et de monitoring (création DB, développement appli, ...), et je ne connait pas vraiment la différence entre les SGDB.

Ce qui signifie que (automatiquement), chaque machine fera remonter des infos

1. Inventaire : chaque machine doit faire remonter son nom, référence des disques, nombre de volume jusqu'au nombre de proc en passant par la RAM, [...], les updates sur ces données seront plutôt rares
2. Monitoring : chaque machine doit faire remonter les données "dynamiques" : ram utilisée, espace disque restant, %cpu, très gros processus, [...] (updates à chaque fois)

La DB doit donc pouvoir un gros trafic (environ toute les 10/15 minutes).

Pour l'instant je suis partie sur PostgréSQL, mon choix vus semble-t-il correcte ?


De plus : la base ci-dessus ne contiendra que la dernière update de chaque partie du système (une ligne dans chaque table par partie et par machine) mais nous voudrions aussi pouvoir historisé les données sans avoir une DB de 1000To dans 3 semaines, bien évidemment rapide lors des requêtes, donc nous pensons que le système aurait une deuxième base prévue à cette effet... en stockant les données au format JSON qui représenterai un gros objet (en plus imbriqué)
Il me semble que le problème des SGDB relationnelle est qu'il est très compliqué (voir impossible) de faire des SELECT en cherchant dans un champ texte aussi complexe.
Pour l'instant j'ai trouvé ElasticSearch.

Malheureusement je ne connais rien à ce genre de DB et n'ai pas la moindre idée quand à la difficulté de l'installation/paramétrage/création

Quelqu'un pourrait-il me conseiller à ce sujet ?

Merci d'avance!

[dadoonet95]

,
Pour l'instant j'ai trouvé ElasticSearch.

Bonjour

C'est une bonne idée d'essayer elasticsearch.
Je te conseille de regarder aussi metricbeat pour remonter justement tous les métriques de tes machines.
Ajoute à cela Kibana et tu auras des dashboards pour voir ce qui se passe sur tes machines.

Filebeat pour les logs. Puis dans Kibana tu auras l'application Logs dédiée à ce besoin.

La suite logicielle te permet d'indexer des pétaoctets de données si besoin, d'être capable de rechercher en fulltext (a la Google) dans ce volume, et le tout en temps réel.

Disclaimer: je bosse chez Elastic.

[StringBuilder]

Bonjour,

Quel nombre de PC allez-vous monitorer ?

Voici rapidement une estimation de la taille des données générées par machine et par an :

Inventaire :
- nom : 30 octets
- référence : 4x40 octets (en comptant large : numéro de série de 4 disque de 40 caractères chacuns)
- nombre de volume : 1 octet (vous avez déjà vu un PC avec plus de 256 volumes ?
- nombre de proc : 1 octet (idem)
- en passant par la RAM : 4 octets (max 4 294 967 295 Mo ça me semble assez large)
- [...] ; allez, soyont grand seigneur, encore 200 octets (dont 4 octets pour l'horodatage)
- les updates : on est chez les fous de la bricole, on va dire 1 fois par 24h

Soit un total de 30 + 160 + 1 + 4 + 1 + 200 = 396 octets par ligne
Soit un total de 393 * 365 = 144 540 octets par an et par machine

Monitoring :
- ram utilisée : 4 octets
- espace disque restant 4 octets
- %cpu : 1 octet
- très gros processus (10x30 octets pour les 10 noms de processus les plus consommateurs)
- [...] allez, encore une fois 200 octets de plus pour stocker des choses oubliées (dont 4 octets pour l'horodatage, et 4 octets pour la référence à la table des PC)

Soit un total de 4 + 4 + 1 + 300 + 200 = 509 octets par ligne
Soit un total de 509 * 365 * 96 (96 quarts d'heures dans une journée) = 17 835 360 octets par an et par machine

Donc un total de 144 540 + 17 835 360 = 17 979 900 octets par an et par machine, soit 18 Mo

Votre supposition de 1000 To en 3 semaines impliquerait donc :

1 000 000 000 / 3 * 52 = 17 333 333 316 Mo par an, soit :

17 333 333 316 / 18 = 962 962 962 PC ainsi monitorés

Travaillez-vous pour les renseignements chinois, la NSA ?

Si on part sur une volumétrie probablement plus proche de la réalité, de 100 PC, il faudra donc 17 333 333 ans pour atteindre 1 000 To. Est-ce que votre estimation vous semble réaliste ?


Maintenant, vous nous parlez d'une base de données contenant deux tables.
On va en rajouter une troisième pour stocker un ID et le nom de chaque PC (youhou !!! 34 octets par machine !!!)

Chaque machine envoie des informations toutes les 15 minutes. Soit 2 requêtes : ce qui fait 100 * 2 / 300 = 0,66 requêtes par seconde
Un SGBD digne de ce nom peut parfaitement ingurgiter plusieurs dizaines de milliers de requêtes par seconde... pour une "vraie application" type ERP ou WMS, c'est à dire avec des calculs, des contraintes d'intégrité, etc.

Donc même une base Access dans votre cas pourrait ingurgiter la charge ! (mais pas la volumétrie à terme, je vous l'accorde)

Bref, avant de commencer à partir sur des solutions de merde à base de stockage JSON, des bases NoSQL dédiées à la BI et autres, commencez par mettre en place votre base de données convenablement, et revenez poser des questions si vous avez de réels soucis de montée en charge.

Sinon, pour en revenir au choix du SGBD, PostGreSQL n'est pas forcément le meilleur choix dans la mesure où pas mal d'opérations d'administration se font exclusivement à froid.
Ceci implique donc une coupure de service pour pouvoir les effectuer, et donc accepter de perdre toutes les mesures envoyées par les PC durant ces opérations.

Depuis que SQL Server tourne aussi sous Linux, je ne vois pas l'ombre d'une motivations qui justifie l'utilisation d'un autre SGBD.

[Firlfire]

(désolée pour ce gros post mais j'ajoute quelques précision sur le projet)

Merci pour vos réponses,
Le projet consiste à développer une appli qui sera installé sur toutes les machines qui doivent être suivie, et elle aura 3 rôles :
- l'inventaire
- le monitoring
- planifier des tâches

Les tâches seront généralement des scripts qu'il devra télécharger et lancer suivant un schedule. Nous considérons que l'inventaire et le monitoring seront ses tâches "principales", obligatoires et assignée d'office à chaque machine.

Pourquoi souhaite-t-on pouvoir stocker des données en JSON :

Ce qui a été prévu pour l'instant pour la DB1 (Postgre pour l'instant, je vais aller regarder plus en SQL Server) :
Comme l'inventaire et le monitoring sont la "base" du projet, ces deux tâches auront leurs propres tables et champs avec des liens entre elles.
Exemple :
Inventaire :
- (table POSTE) moi la machine 'POSTE1' a l'ip 'xxx.xxx.xxx.xxx' j'ai
- (table DISK) `disque 0` 'WD WD10EALS' 'SATA' '3.5"' '1To' '7200 Rpm'
- (table DISK) `disque 1` 'WD WD10EALS' 'SATA' '3.5"' '500Go' '2400 Rpm'
- (table DISK) `disque 2` 'WD WD10EALS' 'IDE' '3.5"' '750Go' '7200 Rpm'
- (table CPUS) `cpu 0` 'Intel® Core™ i9-9900T' 'i9' '4,40 GHz'
- [...]

Monitoring :
- (table VOLUME) `disque 0` 'volume 0' '700Go total' '150Go libres'
- (table VOLUME) `disque 0` 'volume 1' '300Go total' '150Go libres'
- (table VOLUME) `disque 1` 'volume 0' '500Go total' '400Go libres'
- (table VOLUME) `disque 2` 'volume 0' '750Go total' '200Go libres'
- `cpu 0` 'core 1' '50% utilisé' '74°c'
- `cpu 0` 'core 2' '10% utilisé' '74°c'
- `cpu 0` 'core 3' '3% utilisé' '74°c'
- [...]


En revanche, les autres scripts seront créés, testés en locaux puis ajoutés au système et assignés à des machines, chacun d'eux pouvant éventuellement retourner des données à stocker (qu'on ne peut pas vaiment prévoir à l'avance). Et c'est la raison pour laquelle nous souhaitons avoir deux bases :

La DB1 ne gardera que les derniers résultats de chaque tâches (inventaire/monitoring y compris). Et nous souhaitons une autre DB qui gardera l'historique de toutes ses infos. En gros les données de la DB1 seront écrasées à chaque fois alors qu'un nouvel enregistrement/document sera créé en DB2.

Nous ne voulons pas devoir modifier les bases (création de tables, ...) à chaque fois qu'un nouveau script est créé donc :
- La DB1 a une table qui en gros associe le script, la machine et toutes les données dans un champs en JSON : pas de filtre possible sur ces champs, ce n'est pas grave
- La DB2 qui sert d'historisation doit nous permettre de filtrer les résultats sur ses champs 'inconnus pour l'instant'


@dadoonet95 : Je vais aller me renseigner sur les autres produits Elastic dont tu me parles.
Pour Kibana : nous avons déjà une appli Web java interne pour notre support technique et voulons y intégrer dessus pour garder centralisé tout ce qui concerne le support, mais je vais regarder quand même
Pour MetricBeat : fait-il également de l'inventaire ou seulement du monitoring ? Par exemple nous souhaiterions que l'inventaire détecte si il s'agit d'un serveur, et si c'est le cas remonter ses rôles. Peut-il être "intégré" dans une application tierce ? Notre Agent est capable de faire tourner les scripts, pourrait-il communiquer avec MetricBeat pour récupérer les données et les envoyer ? (ou vice-verça)
ElasticSearch (et ElasticStack que j'ai trouvé), je vais me renseigné un peu plus dessus


@StringBuilder : les "1 000 To" était une facon de parler.
La DB dont je parle n'est pas composé que de deux tables, je faisais allusions à 2 de ces trois parties (inventaire, monitoring (la 3eme étnt l'assignation des tâches dont je n'avais pas parler assignation des tâches))
Le gros problème vient du fait que certaines données ne sont pas connu à l'avance, ce qui m'a fait penser qu'un stockage en JSON était mieux adapté (il est possible que je me trompe)

[dadoonet95]

Pour MetricBeat : fait-il également de l'inventaire ou seulement du monitoring ? Par exemple nous souhaiterions que l'inventaire détecte si il s'agit d'un serveur, et si c'est le cas remonter ses rôles. Peut-il être "intégré" dans une application tierce ? Notre Agent est capable de faire tourner les scripts, pourrait-il communiquer avec MetricBeat pour récupérer les données et les envoyer ? (ou vice-verça)
ElasticSearch (et ElasticStack que j'ai trouvé), je vais me renseigné un peu plus dessus

Metricbeat comme tous les autres *Beat est un agent qui collecte de la donnée. Tu ne t'interfaces pas avec Metricbeat. Plutôt tu utilises ce qu'il a collecté.
Je ne pense pas qu'il fasse d'inventaire. Pour cela, je te conseille plutôt de développer en effet ton propre agent qui ira écrire dans son propre index.
Si je t'invite à tester Elastic, c'est pour t'éviter de réinventer la roue en fait. Il y a déjà énormément de choses disponibles par défaut (logs, métriques, APM, réseau, état de service, audit securité, ...)

[SQLpro]

Plus vous multiplierez les bases et plus ce sera la merde pour faire des requêtes croisées (performances catastrophique et requêtes compliquées).
Plus vous aurez de formats de stockage différent tabulaire + JSon plus ce sera la merde pour faire des requêtes croisées (performances catastrophique et requêtes compliquées).

Bref, une seule base, un seul format.

Si vous choisissez PostgreSQL, qui me semble largement suffisant pour ce cas de figure (très peu d'UPDATE) alors faites tout en mode tabulaire et utilisez l'indexation textuelle pour faire de la recherche en texte intégral. Inutile de dupliquer vos données avec, en sus, elasticsearch et donc, avoir deux processus de maintenance à faire avec des migrations......

A +

[StringBuilder]

Je reste quand même convaincu que quelques tables "indicateur_numerique", "indicateur_chaine", etc. avec "cle / valeur" permettra de stocker tout ce que vous voudrez sans devoir faire évoluer le modèle.
Ce ne sera pas forcément ce qu'il y a de plus "propre" niveau modélisation, mais cela permettra toujours de rechercher ce que vous voulez aisément.

Sinon, j'ai pas compris ici l'intérêt d'une indexation textuelle.
Indexer le JSON de cette manière ne permettra pas franchement d'obtenir des résultats probants, et indexer les valeur brutes, encore moins...

Sinon, il ne faut pas avoir peur d'avoir toutes les données historisées dans la base "vivante".

Il suffit de créer cette structure de table :

Code sql :

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
 
create table pc
(
	id int not null identity primary key,
	netbios char(16) unique,
	last_survey_id int null
);
 
create table pc_survey
(
	id int not null identity primary key,
	pc_id int not null references pc(id),
	[ip] binary(4) not null,
	survey_date datetime2 not null default SYSDATETIME(),
	ram_size int not null,
	ram_occupied int not null
);
 
alter table pc add constraint fk_last_survey foreign key (last_survey_id) references pc_survey(id);

Ainsi, lors de l'interrogation de la table PC on récupère directement l'ID de la ligne qui correspond au dernier relevé.

Avec par exemple cette structure pour gérer les disques/volumes :

Code sql :

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
 
create table pc_disk
(
	id int not null identity primary key,
	pc_survey_id int not null references pc_survey(id),
	size int not null,
	serialnumber char(15)
);
 
create table pc_volume
(
	id int not null identity primary key,
	pc_disk_id int not null references pc_disk(id),
	letter char(1) not null,
	size int not null,
	occupied int not null
);

Il est donc très aisé de récupérer la taille restante actuellement sur le disque C de l'ordinateur "pc_bureau" :

Code sql :

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

1
2
3
4
5
6
7
 
select pc.netbios, s.survey_date, v.size - v.occupied
from pc
inner join pc_survey s on s.id = pc.last_survey_id
inner join pc_disk d on d.pc_survey_id = s.id
inner join pc_volume v on v.pc_disk_id = d.id
where pc.netbios = 'PC_BUREAU' and v.letter = 'C';

Tandis que si on veut connaître le min, max et avg sur les 30 derniers jours :

Code sql :

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

1
2
3
4
5
6
7
8
 
select pc.netbios, min(v.size - v.occupied), max(v.size - v.occupied), avg(v.size - v.occupied)
from pc
inner join pc_survey s on s.pc_id = pc.id
inner join pc_disk d on d.pc_survey_id = s.id
inner join pc_volume v on v.pc_disk_id = d.id
where pc.netbios = 'PC_BUREAU' and s.survey_date between dateadd(d, -30, SYSDATETIME()) and SYSDATETIME() and v.letter = 'C'
group by pc.netbios;

Bref, aucune complexité, ni pour l'un, ni pour l'autre.
Et niveau performances, je vois pas trop comment vous pourriez faire mieux.

Pour en revenir au relevés d'autres indicateurs :

Code sql :

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

1
2
3
4
5
6
7
8
 
create table pc_num_indicator
(
	id int not null identity primary key,
	pc_survey_id int not null references pc_survey(id),
	code char(10) not null,
	value int not null
);

On retrouve donc aisément l'indicateur "NB_PRINTERS" (idem, valeur immédiate et valeurs historisées) :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
select pc.netbios, s.survey_date, n.value
from pc
inner join pc_survey s on s.id = pc.last_survey_id
inner join pc_num_indicator n on n.pc_survey_id = s.id
where pc.netbios = 'PC_BUREAU' and n.code = 'NB_PRINTERS';
 
select pc.netbios, min(n.value), max(n.value), avg(n.value)
from pc
inner join pc_survey s on s.id = pc.last_survey_id
inner join pc_num_indicator n on n.pc_survey_id = s.id
where pc.netbios = 'PC_BUREAU' and s.survey_date between dateadd(d, -30, SYSDATETIME()) and SYSDATETIME() and n.code = 'NB_PRINTERS'
group by pc.netbios;

Idem, niveau performances et simplicité, je vois pas trop comment JSON pourrait faire mieux...

[dadoonet95]

Bref, aucune complexité, ni pour l'un, ni pour l'autre.
Et niveau performances, je vois pas trop comment vous pourriez faire mieux.

Je dirais que ça dépend du volume total. En effet, tant qu'on reste sur un seul serveur, qu'on n'a pas besoin de réplication en live des données, il sera peut-être difficile de faire "mieux", tout dépend de ce qu'on entend par mieux. Genre optimiser le stockage? Oui cette solution est mieux. Quoique une database pure timeseries sera peut-être encore mieux optimisée côté espace disque.

Idem, niveau performances et simplicité, je vois pas trop comment JSON pourrait faire mieux...

Simplicité. C'est là que je suis en désaccord. Simplicité pour un développeur, peut-être. Pour quelqu'un de la production qui n'est pas développeur, ça devient plus complexe. Il faut tout créer de la collecte de données, à son stockage et à sa visualisation.

Je recommande elastic (non seulement parce que j'y bosse après avoir utilisé le produit dans l'administration) mais parce que tout cela est fourni clés en main.
Et c'est gratuit (sauf si tu veux commencer à faire de la détection d'anomalies automatisée et autres features commerciales).

Nous avons des utilisateurs qui indexent plus de 10 millions de documents par seconde, des clusters avec des milliards de documents, des pétaoctets collectés.

Bref, un système qui non seulement fonctionne à petit volume (sur une machine) mais capable de passer à l'échelle sans difficulté au fur et à mesure que ton besoin augmente ou que ton service génère plus de data que prévu. Y compris avec de la recherche fulltext, voire floue.

Quoi qu'il en soit, mon conseil est de tester les solutions évidentes (ici PostgreSQL, Elastic, Prometheus...) pour se faire ton propre avis en fonction de ton besoin.
Côté elastic, je pense qu'en 2 ou 3 jours au grand maximum, tu devrais arriver à quelque chose qui soit te séduit, soit te repousse.
Si c'est le dernier cas, j'adorerais entendre pourquoi afin qu'on puisse éventuellement faire évoluer nos produits.

[Firlfire]

@dadoonet95 "tu utilises ce qu'il a collecté" : comment ? cela veut-il dire qu'un programme tiers peut "l'écouter" ? ou bien que MetricBeat enregistre des datas dans une DB et que ce programme devra aller les récupérer ?
Tu m'as conseillé de développé notre propre agent, ce que j'avais déjà prévu (je ne penses pas qu'une des solutions Elastics permette de planifier des scripts tel que je décrit plus haut)
Si j'ai bien compris tu me conseilles d'utiliser MetricBeat pour la partie Monitoring ?

@SQLPro : qu'entendez par "requêtes croisées" ? Une requête sur plusieurs tables ? Je penses que c'est plus la multiplication de table qui complique ce genre de requête.
Pour PostGré je vais aller voir l'indexation textuelle, en revanche pour le côté "très peu d'update" je ne suis pas du même avis : niveau monitoring il y aura potentiellement un UPDATE/INSERT a chaque fois qu'une machine lancera un script (donc plutot fréquent pour moi puisque ce sera toutes les 15 ou 30 minutes)

@StringBuilder : Je voudrais être sûr de bien avoir compris votre exemple :
pc : contient les machines
A chaque nouvel inventaire (chaque jour) et monitoring (chaque 15 min), un nouvel enregistrement est créé dans ces tables :
pc_survey : date de l'inventaire/monitoring
pc_disk et pc_volume : contient les disques et leur(s) volume(s)
pc_num_indicator : contient mes données "non connues pour l'instant" provenant des futurs scripts ?

Si oui, imaginons que nous souhaitons retrouver "tous l'historique des 30 derniers jours pour certaines machines" (simple supposition, mais qui devra peut-être être mise en place par la suite) la requête donnerai quelques chose comme :

Code SQL :

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

1
2
3
4
5
6
7
8
9
 
select *
  from pc
  inner join pc_survey s on s.id = pc.last_survey_id
  inner join pc_disk d on d.pc_survey_id = s.id
  inner join pc_volume v on v.pc_disk_id = d.id
  inner join pc_num_indicator n on n.pc_survey_id = s.id
  where s.survey_date between dateadd(d, -30, SYSDATETIME()) and SYSDATETIME()
  order by s.survey_date

Si j'ai bien compris le contenu de pc_num_indicator, comme résultat nous aurons
- l'historique des 30 derniers jours de chaque machine
- et chaque historique s'affichera plusieurs fois (une fois pour chaque cle/valeur contenu dans pc_num_indicator)

[dadoonet95]

"tu utilises ce qu'il a collecté" : comment ? cela veut-il dire qu'un programme tiers peut "l'écouter" ? ou bien que MetricBeat enregistre des datas dans une DB et que ce programme devra aller les récupérer ?

MetricBeat enregistre ce qu'il collecte par défaut dans Elasticsearch.
Il peut optionnellement envoyer ça vers Redis ou Kafka à la place.

Si j'ai bien compris tu me conseilles d'utiliser MetricBeat pour la partie Monitoring ?

Oui c'est ça. Au moins de le tester pour voir si ça fournit les informations que tu veux.

[Firlfire]

Je suis aller voir de plus près les TSDB et NoSQL :
- TSDB : ça me semble intéressant aussi, j'ai cru comprendre que l'id est une date (logique quand il s'agit d'historisation) ce qui signifie que mon agent devra s'identifier (pas authentifier! ) lui, ses disques, ses volumes, [...] par une date ? (la dernière). Ça peut être intéressant, mais est-il possible, par exemple, de récupérer l'historique du dernier mois seulement pour une/quelques certaine(s) machine(s) (donc identifier les TimeSeries avec deux identifiants : le Time + l'identifiant de la/des machine(s) ?
- NoSQL : d'après ce que j'ai trouvé les plus intéressantes serait une DB de type soit clé/valeur, soit document

MetricBeat enregistre ce qu'il collecte par défaut dans Elasticsearch.
Il peut optionnellement envoyer ça vers Redis ou Kafka à la place.

Donc si j'utilise MetricBeat je devrai forcément choisir entre ces 3 bases ? Donc soit faire une DB, soit mettre en place deux DB : une des 3 pour MetricBeat et l'autre pour le reste

[dadoonet95]

Donc si j'utilise MetricBeat je devrai forcément choisir entre ces 3 bases ?

Kafka et Redis sont des systèmes de messagerie asynchrone (queues) plus que des DB.
Donc tu peux envoyer dans Kafka, lire avec Logstash, enrichir la donnée en faisant un JOIN JDBC (SGBDR), envoyer vers Elasticsearch et vers S3 Amazon et vers Kafka et vers... Bref, c'est hyper flexible.

Je reformule ta question ainsi:

> Donc si j'utilise MetricBeat je devrai forcément choisir entre ces 3 sorties ?

Oui.

[StringBuilder]

@StringBuilder : Je voudrais être sûr de bien avoir compris votre exemple :
pc : contient les machines
A chaque nouvel inventaire (chaque jour) et monitoring (chaque 15 min), un nouvel enregistrement est créé dans ces tables :
pc_survey : date de l'inventaire/monitoring
pc_disk et pc_volume : contient les disques et leur(s) volume(s)
pc_num_indicator : contient mes données "non connues pour l'instant" provenant des futurs scripts ?

Si oui, imaginons que nous souhaitons retrouver "tous l'historique des 30 derniers jours pour certaines machines" (simple supposition, mais qui devra peut-être être mise en place par la suite) la requête donnerai quelques chose comme :

Code SQL :

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

1
2
3
4
5
6
7
8
9
 
select *
  from pc
  inner join pc_survey s on s.id = pc.last_survey_id
  inner join pc_disk d on d.pc_survey_id = s.id
  inner join pc_volume v on v.pc_disk_id = d.id
  inner join pc_num_indicator n on n.pc_survey_id = s.id
  where s.survey_date between dateadd(d, -30, SYSDATETIME()) and SYSDATETIME()
  order by s.survey_date

Si j'ai bien compris le contenu de pc_num_indicator, comme résultat nous aurons
- l'historique des 30 derniers jours de chaque machine
- et chaque historique s'affichera plusieurs fois (une fois pour chaque cle/valeur contenu dans pc_num_indicator)

Chaque remontée des différents PC donnera lieu à un enregistrement dans pc_survey.
Ensuite, toutes données liée à ce pc_survey seront réparties dans les différentes tables qui feront toutes référence à l'id_survey.

Pour ne pas avoir de doublons liées aux multiples indicateurs présents dans pc_num_indicator, il suffit de lier plusieurs fois la table en filtrant à chaque fois sur le type d'indicateur :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
 
select *
  from pc
  inner join pc_survey s on s.id = pc.last_survey_id
  inner join pc_disk d on d.pc_survey_id = s.id
  inner join pc_volume v on v.pc_disk_id = d.id
  inner join pc_num_indicator n1 on n1.pc_survey_id = s.id and n1.code = 'NB_PRINTERS'
  inner join pc_num_indicator n2 on n2.pc_survey_id = s.id and n2.code = 'NB_UNREAD_MAILS'
  inner join pc_num_indicator n3 on n3.pc_survey_id = s.id and n3.code = 'NB_OPEN_TABS'
  where s.survey_date between dateadd(d, -30, SYSDATETIME()) and SYSDATETIME()
  order by s.survey_date

Après, pour les données "tabulaires" (par exemple la liste des disques) on peut utiliser des fonctions d’agrégation de chaînes comme STRING_AGG (SQL Server, PostGreSQL) ou GROUP_CONCAT (MySQL)

Reste d'autres solutions : avec SQL Server par exemple, et probablement d'autres SGBD, tu peux retourner le résultat d'une requête sous forme de XML ou de JSON.

Mais surtout, si c'est pour alimenter plusieurs éléments à l'écran, pour une meilleure réactivité, il vaut mieux faire plusieurs petites requêtes dédiée à chaque widget plutôt que de grosses requêtes qui vont bloquer le chargement de toute la page le temps qu'elle s'exécutent. A ce moment, plus de souci : une requête pour les disques, une requête pour les différents indicateurs, etc.