bonjour à tous
 
je ne suis pas pro sql et j'ai un petit pb de requete (je ne sais meme pas si c'est possible)
 
voici l'exposé du pb qu'on m'a soumis :
trouver s'il existe des entrée d'une table A dont la somme des qty fait la qté d'une entrée de la table B, et le prix moyen pondéré fait le prix de cet entrée de la table B
 
avec un exemple :
CREATE TABLE cv_t(id NUMBER(6), qty NUMBER(6), price NUMBER(13,6))
CREATE TABLE cv_o(id NUMBER(6), qty NUMBER(6), price NUMBER(13,6))
 
INSERT INTO cv_t VALUES (0,20,15.0)
INSERT INTO cv_t VALUES (1,10,5.0)
INSERT INTO cv_t VALUES (2,10,8.0)
INSERT INTO cv_t VALUES (3,11,9.0)
 
INSERT INTO cv_o VALUES (0,40,10.75)
 
il faudrait que je trouve les idx 0,1,2 de cv_t...
 
est ce que ca vous semble faisable ?

Pas en SQL. Ou alors via une PS de taré.

je peux me tromper mais le sujet est surement mal énoncé, fonctionellement tu dois répondre a quelle question?

Trouver un sous-ensemble d'une table A de tel sorte que plusieurs agregations de ce sous-ensemble concorde avec un enregistrement de B : en gros trouver l'ensemble permutations vérifiées par un enregistrement de B.

Et je plussoie MagicBuzz en SQL "pur", pas possible.

Tu es sur que tu dois pas le faire en Transact SQL ou en PL/SQL ?

merci pour à tous pour  vos réponses...  
 
non, je ne suis pas obligé de le faire en sql ; le seul avantage du sql était de pouvoir ajouter la requete sans à avoir à toucher le code de l'appli... mais bon vu vos réponses, je crois qu'au final je vais le faire en c++ (langage de l'appli)
 
bon d'un autre coté, ca me rassure puisque je n'arrivais pas du tout à le faire en sql  

Le C++ sera effectivement un meilleur choix je pense sauf dans un cas : si la table est volumineuse.
 
En effet, le seul moyen de traîter ce problème depuis ton applicatif C++, c'est de charger toute la table en mémoire ou de la lire entièrement plusieurs fois de suite.
Avec un faible volument d'informations (on va dire < 1000 lignes) cela ne devrait pas poser de problème. Mais au delà, tu vas te heurter à de gros problèmes de mémoire (bouffer 500 Mo de mémoire juste pour afficher 3 lignes, ça le fait pas) et de performances (charger quelques dizaines de milliers de fois 1 Million de lignes, ça le fait pas du tout, surtout si tu passes par le réseau pour accéder à la base)
 
Dans ce cas, une fonction en PL te permettra d'améliorer considérablement les performances dans la mesure où les données ne sortirons pas du SGBD pendant la recherche, et que tu utilisera des curseurs pour y accéder, donc une faible consommation mémoire.

PS : Si ça peut t'aider, ton problème c'est la problématique du sac à dos, ensuite une passe pour analyser les différentes solutions et ne trouver que celle(s) qui répond(ent) à la seconde contrainte.
 
http://fr.wikipedia.org/wiki/Probl [...] %C3%A0_dos
 
Grossomodo, à moins de ce lancer dans un algo relativement très complexe, la solution optimale se trouve avec ce type d'algo :
 

pour c de 0 à W faire
  T[0,c] := 0
fin pour
 
pour i de 1 à n faire
  pour c de 0 à W faire
    si c>=w[i] alors
      T[i,c] := max( T[i-1,c], T[i-1, c-w[i]] + p[i] )
    sinon
      T[i,c] := T[i-1,c]
    fin si
  fin pour
fin pour

 
=> Du coup, pour X lignes, tu vas les lire X * X-1 fois (super pas terrible hein, surtout si X est grand... genre 1M )
 
Donc soit tu charges tout en mémoire pour pas trop rammer, soit tu utilises des curseurs depuis le C++. Mais à ce moment, c'est la connexion avec le SGBD qui va sérieusement pêcher.
 
D'où l'intérêt de faire la chose côté SGDB si tu as un nombre important de lignes.

merci pour ton aide MagicBuzz
 
à vrai dire, mes données sont déjà chargées dans l'application; j'ai ajouté un moteur dblite afin de faire des requêtes de type sql en mémoire pour faire des sélections sans avoir à modifier le code...  
 
j'ai en plus déjà un algo de type sac à dos (knapsack) pour faire des associations entre des cv_t et des cv_o, donc ca devrait aller