Discussion :

[fffttt]

Bonjour

je suis sur la création d'un requêteur à destination d'utilisateurs "lambda ++".
Dans le cas d'une requête sur un simple fichier. Ok. Tout va bien.

Mais je cherche un moyen pour représenter les jointures afin qu'ils les construisent le plus simplement possible.

Vous feriez comment ?
merci pour vos avis.

[Narwe]

Je vois 2 pistes.

Le première, compliquée, est de laisser l'utilisateur faire ces jointures. Pour cela, on peut s'inspirer de reprendre ce que propose Windev :


La deuxième, peut-être plus simple est de lister toutes les jointures autorisées par le requêteur dans le programme.
Cela fonctionne uniquement si on connaît la base de données à l'avance.
Par exemple, on sait que le ficher client est lié au fichier facture par la clé IDFacture. Lorsque l'utilisateur sélectionne ces champs, il peut choisir NumFacture du fichier FACTURE et VilleClient du fichier Client. La jointure portera sur la clé IDClient sans même que l'utilisateur est conscience qu'il s'agit de 2 fichiers différents.

[fffttt]

Merci Narwe

la deuxième n'est pas vraiment possible.
1. la base est assez conséquente
2. je n'ai pas forcément et clairement en "natif" les liaisons possibles (comme un idClient qui pourrait se répercuté dans d'autres fichiers)



Au passage, ce n'est pas du HF (et sans liaison). L'utilisateur doit donc réfléchir un minimum (d'où le public "lambda ++") pour créer sa jointure (parmi les clés primaires que je peux lui proposer).
J'ai pensé au côté graphique qu'il y avait (peut être toujours maintenant) dans access 2000.
Mais
1. cela semble galère à mettre en oeuvre
2. je ne suis pas certrain que coté ihm, cela soit finalement une bonne idée.

[fffttt]

j'ai également pensé au champ (FIL)
mais
faudrait que je clone un champ par fichier (possible)
que je fasse les fils par programmation (j'imagine que possible)

mais il faudrait que je stocke toutes les informations pour reproduire le "schéma" (l'idée est aussi de sauvegarder les requêtes créés).
ce n'est peut etr epas la bonne idée.