On connait tous l’intérêt des sondages dans la vie quotidienne. C’est tellement plus facile d’estimer les résultats d’une élection à partir d’un échantillon représentatif plutôt que de demander à tout le monde ses intentions. Les sondages sont également très utiles pour « prédire » l’avenir, par exemple pour une études de marché. Et bien Oracle 10g vous permet de faire des sondages dans vos SELECT. Quel intérêt ? Ça peu aller beaucoup plus vite ! Dans vos applications, selon que vous regardez l’historique de vos ventes pour :

• Faire un arrêté comptable à destination de votre directeur financier
• Estimer les tendance de vos ventes passées pour votre directeur commercial

Le sondage peut ne pas être ou être une bonne idée pour donner un résultat ? Estimez la patience de ces 2 personnes et répondez à la question vous-même ! On s’en fiche ? Si vous avez une table de plusieurs Giga-Octets, cette clause SAMPLE est souvent bien plus redoutable qu’une vue matérialisée, non ?

Pour utiliser cette clause SAMPLE, c’est très simple. Cette requête sur le schema exemple SH :

select t.calendar_year year,
      p.prod_category product,
      c.channel_class channel,
      sum(AMOUNT_SOLD)
 from sh.sales s,
      sh.products p,
      sh.times t,
      sh.channels c
where s.prod_id=p.prod_id
  and s.time_id=t.time_id
  and s.channel_id=c.channel_id
group by t.calendar_year,
         p.prod_category,
         c.channel_class
order by 1,2,3;

Devient simplement :

select t.calendar_year year,
      p.prod_category product,
      c.channel_class channel,
      sum(AMOUNT_SOLD)
 from sh.sales sample(10) s,
      sh.products p,
      sh.times t,
      sh.channels c
where s.prod_id=p.prod_id
  and s.time_id=t.time_id
  and s.channel_id=c.channel_id
group by t.calendar_year,
         p.prod_category,
         c.channel_class
order by 1,2,3;

Remarquez bien que si votre échantillons n’est pas représentatif parce que par exemple vous avez des données mal distribuées ou que le nombre de lignes de la table est trop faible, le résultat peut être très loin de la réalité. Lancez la requête suivante et vous verrez le résultat :

select t.calendar_year year,
      p.prod_category product,
      c.channel_class channel,
      sum(AMOUNT_SOLD)
 from sh.sales s,
      sh.products p,
      sh.times t,
      sh.channels sample(10) c
where s.prod_id=p.prod_id
  and s.time_id=t.time_id
  and s.channel_id=c.channel_id
group by t.calendar_year,
         p.prod_category,
         c.channel_class
order by 1,2,3;

Si vous lancez plusieurs fois la même requête, l’échantillon diffère et le résultat est différent. J’imagine que ça peut être compliqué à expliquer à un utilisateur ; le mot clé SEED(n) où n est une valeur entre 0 et 4294967295 et permet de fixer la manière dont l’échantillon est collecté et ainsi d’avoir le même résultat si les données ne change pas (Ça ne l’empêchera pas de n’être qu’un sondage).

Si vous êtes DBA, je ne vous apprends rien puisque

• Vous collectez déjà les statistiques pour le CBO et que vous connaissez l’intérêt et le danger de la clause SAMPLE.
• Avec 10g vous utilisez surement déjà DYNAMIC_SAMPLING même implicitement avec le paramètre OPTIMIZER_DYNAMIC_SAMPLING

Si vous développez une application… Pensez-y ! En particulier pour vos rapports ou statistiques d’utilisations. Pour en savoir plus sur la clause SAMPLE, reportez-vous à Oracle 10g SQL Reference : « SELECT »