Forum Programmation.SQL Base de donnée temporelle

Posté par  .
Étiquettes : aucune
-1
9
déc.
2011

Bonjour à tous,

J'utilise actuellement une BDD relationnelle (MySQL) pour stocker des
événements.

Tous les événements stockés ont pour dénominateur commun d'être datés
et, plus l'événement est récent, plus il est pertinent. Notons
également qu'ils sont ajoutés chronologiquement à la base de
données. Ainsi, la première entrée d'une table est la plus ancienne.

Lorsque MySQL parcourt une table, il la parcourt du début à la fin, et
donc, de l'entrée la moins pertinente à l'entrée la plus
pertinente. Dans le cas d'une requête simple, l'opérateur ORDER BY
peut être utilisé afin d'inverser l'ordre. En revanche, dans le cas d'une
jointure, cela devient beaucoup plus complexe. Considérons l'exemple suivant:

Table A
Id Date FieldB
1 2010 'a'

Table B
Id Date Field Comment
1 2010 'a' 'com1'
2 2011 'a' 'com2'

$ SELECT A.date , B.Comment from A,B where A.FieldB = B.Field
-> 2010 'com1'

Or j'aimerais que le résultat de la requête soit :
-> 2010 'com2'

En gros, il faudrait que le parcourt interne au moteur soit inversé.

Peut-on utiliser une BDD relationnelle classique pour ce genre d'applications ?
Existe-t-il des moteurs spécialisés pour ce genre d'applications ?

kg.

  • # lapin compris

    Posté par  . Évalué à 4.

    Je suis pas certain d'avoir tout compris, mais je vais essayer d'aider.
    Ton SELECT en question ne te renvoi pas les 2 résultats
    2010 'com1' et 2010 'com2' ?

    Dans ce cas un simple 'order by B.date DESC' ne suffit pas pour ordonner correctement tes résultats ?

    • [^] # Re: lapin compris

      Posté par  (site web personnel) . Évalué à 3.

      Ou s'il n'est intéressé que par la date la plus récente, utiliser max (enfin, si le format de stockage du temps le permet).

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: lapin compris

      Posté par  . Évalué à 0.

      Ton SELECT en question ne te renvoi pas les 2 résultats

      Arf, exact.
      J'ai trop simplifié mon cas réel ...
      Dans ma vraie vie, je fais qq chose comme un AVG:
      Table B
      Id Date Field Comment Integer
      1 2010 'a' 'com1' 1
      2 2011 'a' 'com2' 2

      $ SELECT A.date , B.Comment, AVG(B.Integer) from A,B where A.FieldB = B.Field
      -> 2010 'com1' 1.5
      Et j'aimerais
      -> 2010 'com2' 1.5

      Mais dans tous les cas, le commentaire montre que mon souhait n'est pas réalisable (et erroné)!

      • [^] # Re: lapin compris

        Posté par  . Évalué à 2.

        ah si il est réalisable, mais la requête va pas être piqué des vers ;) L'idée serait de faire une 'vue' contenant les derniers commentaires d'une personne
        CREATE VIEW last_comm AS select field, comm from ...

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: lapin compris

          Posté par  . Évalué à 0.

          Exact. Ou plus simplement (hors considération de performance) avec une requête imbriquée.
          Car j'aimerais bien que ce soit pas trop intrusif dans mon code.

      • [^] # Re: lapin compris

        Posté par  (site web personnel) . Évalué à 1.

        Un truc de ce genre pourrait pas faire l'affaire ?

        SELECT aa.date , (SELECT plop.Comment FROM B plop WHERE aa.FieldB=plop.Field ORDER BY plop.id DESC LIMIT 1) AS Comment, AVG(bb.Integer) from A aa,B bb where aa.FieldB = bb.Field

  • # ASC ou DESC

    Posté par  . Évalué à 6.

    Hello,

    Tous les événements stockés ont pour dénominateur commun d'être datés et, plus l'événement est récent, plus il est pertinent. Notons également qu'ils sont ajoutés chronologiquement à la base de données. Ainsi, la première entrée d'une table est la plus ancienne.

    Tu ne peux pas faire cette hypothèse sans colonne « date » explicite. Une table est considérée comme un ensemble non ordonné. Par exemple, sur SQLPro, l'auteur la présente comme un « sac de billes », ce qui est une métaphore assez parlante. Ça veut dire également, et notamment, que tu peux compter le nombre de tuples identiques dans ta table mais que tu ne peux pas les distinguer les uns des autres (ce qui sera important quand tu voudras en supprimer un).

    Dans ta table, donc, tous tes enregistrements sont placés « là où il y a de la place ». Ça veut dire que tant que tu ne fais qu'insérer des enregistrements, ils vont tous se mettre les uns à la suite des autres, donc dans l'ordre chronologique. Mais dès que tu vas supprimer un enregistrement au milieu de ta table, celui ne sera en fait que « rayé » et le prochain enregistrement que tu vas insérer va prendre sa place.

    Si tu veux garantir l'ordre chronologique sans avoir à trier explicitement ta table à chaque requête, il faut ajouter la colonne date, créer un index sur cette colonne et en faire un « clustered index » si tu veux que ta table soit physiquement triée suivant cette colonne.

    Lorsque MySQL parcourt une table, il la parcourt du début à la fin, et donc, de l'entrée la moins pertinente à l'entrée la plus pertinente. Dans le cas d'une requête simple, l'opérateur ORDER BY peut être utilisé afin d'inverser l'ordre. En revanche, dans le cas d'une jointure, cela devient beaucoup plus complexe.

    « ORDER BY » s'applique sur le résultat, et pas sur les colonnes de la requête au préalable. Tu peux donc trier sans distinction le résultat issu d'une requête simple ou avec jointure. Tu peux également spécifier plusieurs colonnes, séparées par des virgules, pour trier tes tuples selon une première colonne, puis une seconde lorsque les champs de la première sont tous identiques, etc.

    D'autre part, le tri effectué par ORDER est croissant par défaut, mais tu peux à tout moment spécifier le sens avec « ASC » ou « DESC ».

    $ SELECT A.date , B.Comment from A,B where A.FieldB = B.Field
    -> 2010 'com1'
    Or j'aimerais que le résultat de la requête soit :
    -> 2010 'com2'

    Tu peux te référer à une colonne même si elle n'est pas sélectionnée. Donc :

    SELECT A.date , B.Comment from A,B where A.FieldB = B.Field ORDER BY B.Date DESC;

    • [^] # Re: ASC ou DESC

      Posté par  . Évalué à 1.

      un « sac de billes »

      Ok. J'aurais pu m'en douter ...

      en faire un « clustered index »

      Je vais regarder de ce coté, car j'ai l'impression que c'est exactement ce qu'il me faut.
      (j'ai également l'impression que c'est spécifique à sqlpro ...)

      « ORDER BY » s'applique sur le résultat, et pas sur les colonnes de la requête au préalable

      Toutafé, et c'est bien ça mon pb (cf ce commentaire)

      En tout cas, merci pour ce commentaire complet !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.