Discussion :

[pierrot10]

Bonjour,

Il y a quelques années, j'ai fait un schéma avec MySQLWorkbench, avec plusieurs tables et relation.
J'ai importé ce schéma dans MySQL ce qui a construit ma base de données, et j'ai maintenant une belle base de données qui fonctionne bien de depuis.

Dès que j'édite une table qui a une relation avec une autre, et que j'insère une saisie, j'ai un liste déroulante pour sélectionner ma relation
exemple:


J'ai ajouté une relation n:m 'threshold' pour ajouter différents seuil d'alarm en finction du type de station



Etant donné que ma base de données à beaucoup de donnée, je ne pense pas que je peux réimporter ce sachéma.

Dans ma base de donnée, je vais donc créer une nouvelle table 'thersholds',

avec un champs 'stations_id_station' et 'stations_types_id_stations_type' et les et les champs 'label' et 'values'.
Mais je sais que je n'aurai pas un choix déroulant
exemple:


J'aimerais bien donc créer cette table proprement et que dans MySQL considère cette relation.

Ne serait-il pas mieux d'exécuter une requête MySQL pour créer relation n:m en ligne de commande?


Mais comment le faire sans créer un problème sur ma base de donnée, car j'ai vraiement beaucoup d'enregistrements

Merci

[pierrot10]

La challenge que j'ai, c'est que j'ai des niveaux de seuils pour des types de stations.

Par exemple, actuellement, j'ai des stations pour l'irrigation et des stations pour surveiller la température.
Les seuils sont différents, exemple:

température
label | value
===
-4° | -4
-3° | -3
-2° | -2
-1° | -1
0° | 0
1° | 1
2° | 2

Irrigation
label| value
===
0-10kPa | 10-20
10-30kPa|10-20
30-60kpa | 30-60

Si une station est de type 'irrigation', elle va utiliser les Threshold Irrigation, si elle est de type température elle va utiliser les threshold de -4 à 2

Mais je ne suis pas sûre je m'y prends bien.

Il faudrait avoir une table qui liste les seuils des températures et une autre qui liste les seuils de l'irrigation. Mais comment dire à la station en fonction de son type, la table 'des seuils' qu'elle doit utiliser???

[escartefigue]

Bonjour,

Quand on veut modéliser correctement une base de données, la première des choses à faire est de rédiger les règles de gestion, c'est essentiel.
Pour ce faire, suivez ce fil de discussion dans lequel la réponse n°8 explique comment les rédiger.

Ici, si je comprends bien, les règles sont les suivantes (merci de confirmer et corriger si nécessaire)

R001 : une station est caractérisée par un et un seul type de stations
R002 : un type de stations peut caractériser zéro à plusieurs stations

R003 : un type de stations est limité par un à plusieurs seuils
R004 : un seuil limite un et un seul type de stations.

Si tel est bien le cas, le modèle conceptuel des données est le suivant :



Ce qui donne le MLD suivant :



Notes :

• j'ai utilisé des termes en français : il n'y a aucun intérêt à se compliquer la vie avec de l'anglais si le projet est francophone ;
• ce modèle est simplifié, il faut le compléter avec les attributs manquants ;
• j'ai proposé dans ce modèle une notion de seuil mini et maxi, à vous de voir si c'est opportun ;
• ici, le seuil est identifié relativement au type de station, le seuil étant une entité-type faible du type de station, d'où les cardinalités avec (R) entre parenthèses ;
• dans votre modèle, la station est en relation avec le seuil, c'est une erreur, le seuil ne doit être lié qu'au type de station, c'est par transitivité qu'on connait les seuils d'une station (en passant par son type) ;
• dans votre modèle, le type de station est associé à au moins une station, là aussi c'est le plus souvent une erreur : les typologies doivent autoriser un minimum de zéro, car à un instant "t" il est fort possible qu'on n'ait aucune occurrence d'un type.

EDIT : ce qui me surprend ici c'est l'absence de notion de sonde.

Habituellement, une station possède une à plusieurs sondes (sonde de température, de pression, de vitesse du vent...), chaque sonde est associée à une unité de mesure (° Celsius, millibar, m/s...) et éventuellement à des seuils
Ici vous ne parlez pas de sonde, est-ce normal ?

[escartefigue]

Attention aussi aux noms des colonnes et à leur typage.
Pour la valeur du seuil, "VALUE" est un mot réservé SQL, du coup, si on le choisit comme nom de colonne, il faudra encadrer celui-ci par des délimiteurs, ce qui est très pénible à l'usage.
À ce titre, utiliser l'anglais pour nommer les tables et leurs attributs augmente le risque de percussion avec les mots réservés SQL. Un argument de plus en défaveur de l'utilisation de l'anglais quand ce n'est pas contraint par un contexte international.
Utiliser un préfixe d'entité comme je le fais quand je suis libre de la codification élimine ce risque, par exemple, avec le préfixe SE utilisé pour la table des seuils SE_seuil, la colonne serait nommée SE_value et ainsi plus de probème avec les mots réservés et plus besoin de s'embêter avec les délimiteurs

Également, un type char ou varchar est inadapté pour une mesure, il faudra un type numérique, probablement décimal ou éventuellement integer si ce sont des valeurs entières.
Je ne l'ai pas précisé dans mon modèle simplifié, mais une mesure doit être accompagnée de l'unité de mesure.

[pierrot10]

Hello
Je vous remercie pour vos réponses. (Je lis votre message maintenant).
Entre temps, je me suis posé la question si je devais d'abord me consacrer aux utlisateurs.

Ma soucis de clareté, j'apporte plus de détails (j'aurais dû le faire avant) afin de comprendre les modifications que je dois apporter à ma base de donnée

Il y a quelques année j'ai mis en place de projets. Des stations étaient installés dans des terrains. (station météo, irrigation, et pour lutter contre le gel de printemps). Les mesures sont envoyées via le protocole LoRaWAN et elles sont sauvegardées dans une base de donnée. Ca fonctionne super bien .

Sans trop de connaissances, j'ai fais une application pour SmartPhone avec Cordova.

Ces projets pilotes sont terminés, mais j'ai entrepris de refaire mon application pour SmartPhone avec React Native. Cette application a une API qui va faire des requetes sur ma base de données et retourner les resultats en JSON. J'affiche des status, des stations et les graph des mesures.

Pour revnir à mon sujet, je souhaite implémenter les Push Notification et améliorer le système d'alarme pour en recevoir sur le SmartPhone quand une mesure(s) est(sont) critiqe(s). Pour cela, le contrôles des mesures doit faire côté serveur pour une push notification soit envoyée aux téléphones.

Je dois donc modifier ma base de données pour avoir un nouveau tableau qui mémorise les valeurs seuil (thresholds). Cet après-midi, j'ai réalisé que j'ai pas assez réflaichi , car ils ne faut pas que les nofications soient envoyés à TOUS les téléphones mais aux téléphones (utilisateur) qui est proriétaire d'un ou de plusieurs terrains. Donc, je pense qu'il faudrait que je penche sur les tables qui vont contenir les utilisateurs, avant...

J'avais déjà commencé ceci


mais il faudra que j'efface ces deux tables et que je les recrée proprement, car apparement (je me trompe peut-être) MySQL ne fait pas la lisaion, puisque je n'ai pas menu déroulant pour sélectionner un utilisateur ou un terrain déja existant. Je dois saisir manuellement l'ID de mes users ou terrain

alors que pour mes autres liaisons (par exemple, quand je crée un sonde) il me propose des choix.

Pour répondre à la question d'ecatefirgue, je vais essayer d'établir ces règles. J'espère bien faire

R001: Un terrain a des attributs qui définis sa position et la date de création
R002: Un terrain est attribué à un ou plusieurs comptes utilisateur.
R003: Un compte peut être attribué à plusieurs terrains
R004: Un terrain contient une ou plusieurs stations
R005: Un terrain peut avoir une ou plusieurs station
R006: Une station est représentée par un type (météo, irrigation, gel) et un type peut être attribué à plusieurs stations.
R006: Une station à plusieurs sondes et des sondes peuvent être attribuées à plusieurs station
R007: Une station conteint un valeur critique (threshod) qui dépend du type de terrain

exemple:
gel: -5+ à 12° (si en dessous, génère un notification push)
irrigation: 0-10, 10-30, 30-60 (si en dehor de, génère un notification push)

NB:
Le seuil critique d'une batterie d'une station est la même pour toutes les stations et ne peut pas être paramètrée/chagée
Il n'y a pas de seiul critique pour une station météo. Ce n'est pas le sujet aujourd'hui, mais si je devait le faire, j'aurai un autre problème car une station météo à plusieurs sonde (vent, rayonnement solaire, température, pression, humidité)

R008: Une station pourrait changer de type, mais c'est un cas très très rare
R009: Une station gànère une alarme quand une sonde mesure une valeur critique est sauvegarde l'événement dans la table 'alarms'
R010: Une station mesure une collection de mesures toutes les 60mn (une collection de mesure est l'ensemble des mesures des sondes qui sont attachées à la station)
R011: Une sonde contient plusieurs mesures
R012: Une sondes contient plusieurs attributs (ID, nom, description, active, date de création)
R013: Une sonde peut contenir encore d'autres attributs pour la représentation graphique des mesures. Elle peut contenir une des ses valeurs (couleur, style du graph, épaisseur, etc). Ces attributs peuvent être attribués à plusieurs sondes.

Voilà ,j'espère avoir bien répondu à ta question en établissant des règles. Est-ce bien ce que tu demandes?
A mon avis, ce qui concerne ma problématique actuelle, soit d'ajouter des nouvelles tables, se sont les règles de R001 à R010, non?

J'aimerais donc bien créer mes nouvelles tables et avoir un choix comme lorsque je crée une sonde pour une station où j'ai le choix de sélectionner une station ou a type de sondes existants



Ai-je raison de penser que si on n'a pas ce choix, la table n'est pas bien liée/créée?

[escartefigue]

Bonjour Pierrot10,

Merci pour les règles de gestion, ça va faciliter la compréhension et les échanges.

Je m'interrogeais sur l'absence de sondes, je vois qu'elles sont finalement bien présentes, mais, concernant ces règles :

R006: Une station à plusieurs sondes et des sondes peuvent être attribuées à plusieurs station
R007: Une station conteint un valeur critique (threshod) qui dépend du type de terrain

Si j'arrive à comprendre facilement qu'une station contient plusieurs sondes, à l'inverse, j'ai du mal à imaginer comment une sonde peut être attribuée à plusieurs stations.
Habituellement, une station est localisée à un endroit précis et possède plusieurs sonde (par exemple : une sonde de température, une sonde de pression atmosphérique et un anémomètre pour la vitesse du vent)
Ce faisant, une même sonde ne peut être attribuée qu'à une seule station. Ou alors, il faut ajouter une notion temporelle pour pouvoir localiser telle sonde dans telle station à tel instant.


Concernant la règle R009 :

R009: Une station génère une alarme quand une sonde mesure une valeur critique est sauvegarde l'événement dans la table 'alarms'

Cette règle implique que la valeur critique (le seuil donc ou "threshold") est liée à la sonde et non pas à la station.


À propos de la règle R010

R010: Une station mesure une collection de mesures toutes les 60mn (une collection de mesure est l'ensemble des mesures des sondes qui sont attachées à la station)

Si la collection est porteuse d'attributs, alors il faut la matérialiser par une entité-type au niveau conceptuel (un rectangle du MCD), entité-type qui deviendra une table.
Si ce n'est pas le cas, on se contentera de collecter toutes les mesures d'une même heure et d'une même station pour constituer la collection par traitement et on oublie cette notion dans le modèle de données.
Bien évidement, chaque mesure doit être horodatée et ce qu'on ait ou non besoin de gérer des collections.


Relativement aux règle R011 à R013

R011: Une sonde contient plusieurs mesures
R012: Une sondes contient plusieurs attributs (ID, nom, description, active, date de création)
R013: Une sonde peut contenir encore d'autres attributs pour la représentation graphique des mesures. Elle peut contenir une des ses valeurs (couleur, style du graph, épaisseur, etc). Ces attributs peuvent être attribués à plusieurs sondes.

Le terme "contient" est inapproprié, pour plus de clarté, on dira plutôt
R011 : une sonde effectue une à plusieurs mesures, chaque mesure étant horodatée.
R012 : une sonde possède des ou est caractérisée par ou est porteuse d'attributs
R013 : idem R012

Ai-je raison de penser que si on n'a pas ce choix, la table n'est pas bien liée/créée?

Oui, le modèle n'est à priori pas conforme au besoin, sous réserve des réponses à mes questions ci-dessus

[escartefigue]

Voici un modèle qui semble correspondre au besoin.

Je n'ai pour l'instant pas intégré la notion de collection, nous pourrons l'ajouter si le besoin est avéré.
La relation ternaire (PO_posseder) entre [TE_terrain], [PE_personne] et l'entité-type fictive [CA_calendrier] permettra de n'envoyer les alertes qu'aux personnes qui possèdent le terrain au moment de l'envoi (les anciens propriétaires n'étant probablement plus concernés).
[CA_calendrier] ne deviendra pas une table, elle n'intervient que pour faire participer la date à l'association, c'est pourquoi elle apparait entre parenthèses et n'est plus présente dans le MLD.

EL_element contiendra le type d'éléments mesurés (pression, température, vitesse du vent...) en association avec une unité de mesure (hectopascal, °C, m/s...)
ME_mesure contiendra les mesures proprement dites, l'unité de mesure de la mesure étant celle de l'élément mesuré par la sonde ayant effectué la mesure.

Ici j'ai considéré que les personnes sont toutes des personnes physiques avec un nom et un prénom, mais si certains propriétaires sont des personnes morales, alors il faudra enrichir le modèle.

Ce qui donne au niveau conceptuel :



Et au niveau tabulaire :

[pierrot10]

Hello

Merci pour tout. Je vais lire attentivement vos message ce soir.
J'ai rapidement lu une question

Si j'arrive à comprendre facilement qu'une station contient plusieurs sondes, à l'inverse, j'ai du mal à imaginer comment une sonde peut être attribuée à plusieurs stations.

Oui j'ai bugué En effet, une station peut contenir plusieurs sondes, mais une sonde ne peut appartenir qu'a une station. Il peut avoir plusieurs mêmes sondes, mais évidemment que physiquement une sonde appartient à une station.

Je revins plus tard après avoir bien lu vos messages

[pierrot10]

Helloooo

Miiiilles mercis pour tous tes efforts. J'apprécie énormément.

J'aimerais juste refaire un petit point. J'avais cette base de donnée, il y a bien des années en me débrouillant comme je pouvais sans faire des règles comme tu viens de me l'apprendre. Il est donc fort propable que certains principes ne sont pas respecter. Par exemple, tu as évoqué la nomanclanture des tables et des colonnes. J'avais suivi un tuto avec CakePHP qui maintait le nom des tables aux pluriels. Aussi tu évoqué de ne pas utilisé des mots réservés comme 'value'. C'est noté, lors de la création de mes futures tables, je n'utiliserai pas ce nom value, mais peut être 'valeur' ou autre.....

J'aimerais préciser que ma base de données à plus d'un millions de mesures et j'ai trop peur de prendre des riques et tout casser et puis je n'ai pas les ressouces (en temre de temps pour tout refaire). Je précise cela pour ne pas tu t'engage trop dans la direction de tes recommandations. malgré ceci, le but principale est d'ajouter proprement à ma base de données des nouvelles tables

Pour l'authentification
* Users
* fileds_has_users

Pour la gestion des alarmes
* tresholds
* stations_types (ou stations_has_treshold

Tu as solevé un point très intéressant (j'espère que rien louper dans tes observations)

Concernant la règle R009 :
Citation Envoyé par pierrot10 Voir le message
R009: Une station génère une alarme quand une sonde mesure une valeur critique est sauvegarde l'événement dans la table 'alarms'
Cette règle implique que la valeur critique (le seuil donc ou "threshold") est liée à la sonde et non pas à la station.

Il faut que j'explique un point de mon projet.

• J'ai des stations qui mesurent la température à proximité des bourgeons pour lutter contre le gel de printemps. Ces stations n'ont que deux sondes de température et le mcricontrolleur mesure l'état de la batterie. La station a donc 3 sondes (dans la DB) dont deux physiques
• J'ai des stations qui mesurent le taux hydrique dans le sol des cultures. Elles ont 5 sondes: 2 pour mesurer la teneur en eau dans le sol, une pour la batterie, une pour mesurer l'arosage, 2 pour la pression et l'humidité

Pour ces deux applications, seulement les sondes pour mesurer la température des bourgeons et les 2 sondes pour mesurer le teneur en eau dans le sol, sont concernées par les alarmes.

En gros, si une des sondes de températures (bourgeons) mesure un valeur en dessous du seuil (treshold), mon API dont envpyer une push notification à mon App pour Samrtpohone.
Idem pour les sondes mesurant la teneur sans le sol.

Donc, si une des sondes s'exite, la station passe en mode 'alarme'. Les mesures sont envoyées et dès que mon serveur les recoit, il doit envoyé une push notification.

C'est pourquoi la règle R009.

Pour ne pas compliquer, je ne veux pas penser aux stations météo, car j'ai aussi des stations météo qui ont 8 sondes

• Température ambinate
• Pression
• Humidité
• Rayonnement solaire
• Vitesse du vent
• direction du vent
• batterie
• Précipitation

Pour revebir tu ta remaqrue

Cette règle implique que la valeur critique (le seuil donc ou "threshold") est liée à la sonde et non pas à la station.

Ben en travaillant sur ce sujet avant de poster mon message, je me demandais si je ne devait pas mieux travailler les alarmes sur les sondes et pas les stations, parce qu'on pourrait me demander qu'un utilisateur soit informer si le vent est trop fort.

En écrivant mon premier message, hier, je me suis reste symple, reste sur les stations (pour les seuil) comme le projet fonctionnait initialement.

Masi, là (en écrivant ces lignes), je vais changer les règles et agir sur les sondes. Je pense que c'est mieux et ca m'éviterais de revenir sur mon travail si on me demande que la station se met en alarme si le vent uniquement est trop fort. Je vais donc changer les règles ainsi (en gras les corrections)

J'ai supprimé la règle 5, car elle est identique à la 4

R001: Un terrain a des attributs qui définis sa position et la date de création, etc
R002: Un terrain est attribué à un ou plusieurs comptes utilisateur.
R003: Un compte utilisateur peut être attribué à plusieurs terrains
R004: Un terrain contient une ou plusieurs stations
R005: Un terrain peut avoir une ou plusieurs station
R006: Une station est représentée par un type (météo, irrigation, gel) et un type peut être attribué à plusieurs stations.
R006: Une station peut avoir une ou plusieurs sondes physiques. Elle a par défaut une sonde "virtuelle" car la station mesure l'état de la batterie
R007: Une sonde conteint un valeur critique (threshod) qui dépend du type de station
R008: Une station ne peut pas changer de type
R009: Une station passe en mode "alarme" quand une sonde mesure une valeur critique. L'événement est sauvegarde l'événement dans la table 'alarms'
R010: Une station mesure une collection de mesures toutes les 60mn (une collection de mesure est l'ensemble des mesures des sondes qui sont attachées à la station)
R011: une sonde effectue une à plusieurs mesures, l'une après l'autre et la collection de mesures est horodatée.
R012: une sonde possède des ou est caractérisée par ou est porteuse d'attributs
R013: Une sonde peut contenir encore d'autres attributs pour la représentation graphique des mesures. Elle peut contenir une des ses valeurs (couleur, style du graph, épaisseur, etc). Ces attributs peuvent être attribués à plusieurs sondes.

Si la collection est porteuse d'attributs, alors il faut la matérialiser par une entité-type au niveau conceptuel (un rectangle du MCD), entité-type qui deviendra une table.

Là, je te suis pas. Une station à un microcontrolleur qui "tourne à vide". Tous les x temps (60mn dans mon cas) il "ordonne" aux sondes de prendre les mesures qui les prennent une après l'autre. Mais la station les envoit en même temp sous la forme d'une string

Exemple: a23b43c675d987e56f3d

Les lettres correspondes à une sonde et les chiffre sont les valeurs. Mon script PHP, dlcortique cela et les sauves dans la BD. Ca fonctionne nikel

C'est pourquoi que j'ai appelé ça une collections de mesures. Peut-être que R010 peut être ignorée.

Je n'ai pour l'instant pas intégré la notion de collection, nous pourrons l'ajouter si le besoin est avéré.

Non elle important. Pas dans le cadre de mon travail actuel, soit d'ajouter les tables pour la gestion des utilisateurs et des alarmes (treshold).
Elle importante car elle mémorise l'horodatage (collection_created) des mesures (=collection de mesures). Je prends très souvent cette valeur dans mon App Web et Smartphone, pour ordonner l'affichage des mesures, par exemple. Elle mémorise aussi les valeurs de la férquence, par exemple que je mémorise mais que je n'utilise pas dans mon App.



La table 'gateways', mémorise les données de la passerelle qui a fait le relai entre mes stations et mon serveur. Mais ca, ce n'est abslument pas important dans ce sujet


Mon obectif est

• d'ajouter les tables 'Users' et 'users_has_fields' proprement et
• d'auter une table 'tresholds' qui va mémoriser les valeurs disponibles

La grosse difficulté que je vois dans la table 'thresholds', c'est qu'il y a des seuils différents en fonction du type de sonde.
Par exemple (les deux premières sont les plus importante)

• la température: -5° à 3° (ou plus)
• taux hydrique: (0-20)(20-40) etc
• vent : 30, 50,100, etc
• direction du vent: 0 à 360

Etant donné que mes sondes, il y a aussi des types (température, rayonnement, vent, précipitation qui ont un identifiant unique), j'imagine une table 'tresholds' ainsi

tresholds
id_treshold (int) | sensors_type (int) | label (varchar) |treshold (varchar)
===
1 | 1 | -3° | -3
2 | 1 | -2° | -2
3 | 1 | -1° | -1
4 | 1 | 0° | 0
5 | 1 | 1° | 1
6 | 1 | 2° | 2
7 | 2 | 0-10k Pa | 0-10
8 | 2 | 10-30 kPa | 10-30
9 | 2 | 30-60 kpa | 30-60
10 | 2 | 60-100 kpa | 60-100
11 | 2 | 100-200 kpa | 100-200
12 | 3 | 5 km/h | 5
13 | 3 | 10 km/h | 10
14 | 3 | 30 km/h | 30
15 | 3 | 60 km/h | 60
16 | 4 | 5mm | 5
17 | 4 | 10mm | 10
18 | 4 | 20mm | 20
19 | 5 | 10k Pa | 0-10
20 | 5 | 30 kPa | 30
21 | 5 | 60 kpa | 60
22 | 5 | 100 kpa | 100
23 | 6 | 10 W/m2 | 0-10
24 | 6 | 30 W/m2 | 30
25 | 6 | 60 W/m2 | 60
26 | 6 | 100 W/m2 | 100

Les valeurs si dessus sont arbitraires.
Catégories:
1 : température bourgeons
2 : teneur en eau dans le sol
3 : vitesse du vent
4 : précipitations
5 : pression atmosphérique
6 : radiation solaire
... et encore

Je précise encore qu'actuellement, ce qui m'importe c'est surtout la température et la teneur en eau dans le sol


Mais comment préparer ces nouvelles tables proprement, même si ma structure actuelle pourrait être mieux ?


J'espère avoir apporter une réponse à tes question et clarifier la situation

Milles merci pour ton aide

[pierrot10]

Ca c'est une idée

tresholds
id_treshold (int) | sensors_type (int) | label (varchar) |treshold (varchar)
===
1 | 1 | -3° | -3
2 | 1 | -2° | -2
3 | 1 | -1° | -1
4 | 1 | 0° | 0
5 | 1 | 1° | 1
6 | 1 | 2° | 2
7 | 2 | 0-10k Pa | 0-10
8 | 2 | 10-30 kPa | 10-30
9 | 2 | 30-60 kpa | 30-60
10 | 2 | 60-100 kpa | 60-100
11 | 2 | 100-200 kpa | 100-200
12 | 3 | 5 km/h | 5
13 | 3 | 10 km/h | 10
14 | 3 | 30 km/h | 30
15 | 3 | 60 km/h | 60
16 | 4 | 5mm | 5
17 | 4 | 10mm | 10
18 | 4 | 20mm | 20
19 | 5 | 10k Pa | 0-10
20 | 5 | 30 kPa | 30
21 | 5 | 60 kpa | 60
22 | 5 | 100 kpa | 100
23 | 6 | 10 W/m2 | 0-10
24 | 6 | 30 W/m2 | 30
25 | 6 | 60 W/m2 | 60
26 | 6 | 100 W/m2 | 100

après il faudra un table de liaison probalement appelée 'sensors_has_tresholds' qui lie la sonde (id_sensor) à l'id du seul (id_treshold) ou un truc du genre, non?

sensors_has_tresholds (exemple)
id | sensors_id_sensor | tresholds_id_treshold
===
1 | 1 | 1
2 | 2 | 3
3 | 3 | 7
4 | 4 | 8
5 | 10 | 12
6 | 11 | 25
et encore ...


N'est-ce pas?