Discussion :

[=JBO=]

Bonjour,

Dans un fichier (table d'une BD HF) j'ai besoin de gérer n options de type booléen.
Dans ma réflexion l'alternative serait:
(a) n rubriques de type booléen,
(b) 1 rubrique tableau de n éléments booléens.

A terme, je veux filtrer les données, exécuter des requêtes, en appliquant des critères de sélection sur une ou plusieurs options (le "plusieurs" est important).

Avec plusieurs rubriques je sais faire, c'est facile. Mais le nombre d'options étant amené à augmenter, je ne voudrais pas avoir à modifier la structure de mon fichier table en ajoutant de nouvelles rubriques.

Aussi je suis intéressé par une rubrique tableau que je pourrais sur-dimensionner largement afin de pouvoir intégrer de nouvelles options sans modification de l'analyse ni de mon code.
MAIS je ne trouve aucune information concernant la façon de filtrer/requêter un fichier sur un ou plusieurs éléments d'une rubrique tableau !?

Là comme ça, j'ai vraiment l'impression que c'est une impasse...

Si quelqu'un avait des informations, je lui serai très reconnaissant de nous les dévoiler (comme ça on pourra compléter la doc en ligne qui est muette sur le sujet ).

Merci.

[mail.spam]

Bonjour, JBO

Une idée comme ça...
Je ferai une table qui contient la liste de mes variables booléennes.
Puis dans ton fichier je rajouterai un champ Condition contenant une chaine binaire.

Ainsi
tu garde dans ta base un fichier avec la liste des conditions ainsi que le bit auquel elle correspond.

condition / bitbinaire
a / 0
b / 1
c / 2
d / 3
e / 4
f / 5
etc...
ainsi si condition a vrai alors le bit 0 de ta condition binaire est à 1

donc pour a = vrai, b et c = faux d est vrai
alors condition (valeur binaire sur 8 pour l'exemple) est 00001001

ainsi il suffit que tu fasse la conversion de tes condition en binaire.

j'espère que je suis clair dans ma logique.

[=JBO=]

Salut mail.spam et merci pour ta proposition.

C'est pas mal du tout comme idée.

Sur un entier long (4 octets) je peux coder 32 options, c'est bien suffisant pour mes besoins.
De toute façon, mon critère de sélection, j'allais le construire dans le code. Alors pourquoi pas coder mes options dans une valeur binaire.

Mais j'ai encore un doute par rapport à cette approche: comment l'utiliser dans un filtre ou une requête ?
(au fait je suis encore en Windev 12)

Dans une requête, je devrais me servir de la fonction ETBinaire() mais peut-elle être utilisée en SQL ?

En revanche, dans un filtre, ne crois pas que je puisse utilise l'opérateur ET binaire (&).

Je vais devoir faire des tests...
En tout cas merci beaucoup pour ton aide à la réflexion.

Sinon, je reste ouvert à toute idée sur l'utilisation directe des éléments d'un tableau.

[mail.spam]

Je n'ai aucun recul pour les filtres et la fonction ETBinaire() en SQL.
C'étais juste une hypothèse de travail.

Désolé de ne pouvoir t'aider plus.
Mais je suis curieux d'avoir le retour de tes recherches.

[vmolines]

SVP oubliez les rubriques de type tableau ou la définition de plusieurs valeurs dan une rubrique à coup de ETBINAIRE (Désolé mail.spam).

Une modélisation possible et plus logique. Exemple avec des voitures

Voiture = {IDVoiture, ... }
Option = {IDOption, Designation, ... }
Voiture_Option = {#IDVoiture, #IDOption}

Vous pouvez ajoutez autant de nouvelles options que vous voulez sans ajouter X rubriques. La présence d'une ligne dans Voiture_Option indique que la voiture IDVoiture possède l'option IDOption.

edit : précision concernant le type tableau (en BDD), c'est une abération, les tables sont faites pour ça !!!

[=JBO=]

SVP oubliez les rubriques de type tableau ou la définition de plusieurs valeurs dan une rubrique à coup de ETBINAIRE (Désolé mail.spam).

[...]

edit : précision concernant le type tableau (en BDD), c'est une abération, les tables sont faites pour ça !!!

@ vmolines
Je comprends que tu sois contre l'utilisation d'une rubrique tableau, et pour ma part je ne la conseillerai à personne non plus.
Sur ma motivation: je veux gérer des options le plus simplement possible et le faire au plus vite, sans contrainte de portabilité ni de respect des règles de l'art.

Alors voici le résultat de mes tests.
Pour résumer, l'accès aux éléments d'une rubrique tableau marche aussi bien dans un filtre que dans une requête SQL.

En fait, la syntaxe indicée (avec l'indice entre crochets) fonctionne dans les 2 cas.
Si on omet l'indice, alors c'est l'élément d'indice 1 qui est manipulé.

Par exemple, j'ai un fichier Table MON_FIC avec une rubrique tableau numérique de 16 éléments, nommée N_OPTIONS.

Les deux lignes ci-dessous sont équivalentes:

Code WLangage :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
HFiltre(MON_FIC,"N_OPTIONS=5")
HFiltre(MON_FIC,"N_OPTIONS[1]=5")

Après, avec l'indice on peut manipuler plusieurs éléments, comme si c'était des rubriques distinctes:

Code WLangage :

Sélectionner tout - Visualiser dans une fenêtre à part

HFiltre(MON_FIC,"N_OPTIONS=1 OU N_OPTIONS[5]=2")

Dans une requête SQL, la rubrique tableau peut être utilisée avec ou sans indice, dans la clause SELECT ou la clause WHERE.

Une limitation en SQL: impossible de paramétrer l'indice.
En effet, apparemment la valeur de l'indice doit être une constante numérique.
Il est impossible d'utiliser une expression, une autre rubrique de la requête ou un paramètre de requête pour définir la valeur de l'indice: sinon une erreur se déclenche.

Une absence regrettable aussi:
il n'y a pas de syntaxe permettant de tester la valeur de n'importe quel élément, ou d'un ensemble d'éléments pris dans un intervalle...
Un truc du genre:

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE N_OPTIONS[*]=5

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE N_OPTIONS[2 TO 5] In (1, 2, 3)

quoi !?... on a le droit de rêver...

[vmolines]

Ce n'est pas plus rapide de mettre en place une vraie table qu'un tableau.
Ajouter une option revient à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

INSERT INTO Option (Designation) VALUES ('Nouvelle option')

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Option.Designation = "Nouvelle option"
HAjoute(Option)

Où est la complexité et en quoi n'est ce pas rapide ? Je veux qu'on m'explique.

Vous parlez de contrainte de portabilité ? portabilité vers quoi ? Ce qui est sûr c'est qu'une table sera bien plus portable qu'une colonne de type tableau.

Je ne privilégie pas cette modélisation pour respecter des règles d'art mais simplement de logique. Est-ce que lorsque vous avez besoin de stocker un entier, vous stockez sa valeur dans une chaîne en évoquant ce même argument qu'est de ne pas respecter les règles de l'art ?

Vous dîtes vous même que vous ne conseilleriez cette solution à personne, commencez par vous .

Toutes les besoins en terme de requête que vous évoquez sont facilement réalisables avec cette modélisation. Que vous faut-il de plus pour faire les bons choix ?

[OnePoint]

Salut.

Je suis content, j'ai appris quelque chose sur Hyper File.

Quant au 2ème msg de vmolines , je trouve que ça tourne au troll, la mise en garde dans le 1er msg était bien suffisant.

Et puis faut se calmer avec la pensée unique !
La discussion c'est "Comment utiliser une rubrique tableau ?" et pas "Doit-on utiliser une rubrique tableau ?", ni "Comment bien modéliser les options ?".

Libre à toi vmolines de créer ton propre fil sur ce thème différent sans plus polluer celui de jbo. Merci.

[hpascal]

Bonjour

Je me permets de réagir au message de OnePoint

Il ne faut pas s'emballer

Les gens qui interviennent ici sont la pour donner des conseils, notamment vmolines

Et proposer une autre solution ça ne s'appelle pas un "troll", surtout quand cette solution s'avère judicieuse et argumentée.

Maintenant, savoir comment fonctionne les rubriques Tableau est très bien pour ceux qui veulent les utiliser.

Bonne journée

[OnePoint]

Je me permets de réagir au message de OnePoint

Il ne faut pas s'emballer

Les gens qui interviennent ici sont la pour donner des conseils, notamment vmolines

Et proposer une autre solution ça ne s'appelle pas un "troll", surtout quand cette solution s'avère judicieuse et argumentée.

De mon point de vue, le 2ème msg de vmolines est hors sujet et n'apporte rien de plus que son 1er msg.
Le ton vindicatif de vmolines "diabolise" le sujet même de ce fil du genre <<les rubriques tableau c'est mal>>
Vmolines émet des jugements à l'emporte pièce (le seul bon choix passerait par l'utilisation d'une table d'options) alors qu'il ne connaît pas précisément les objectifs de JBO.

Voila pourquoi je trouve que ça tourne au troll.

[vmolines]

En effet il n'apporte rien par rapport à mon 1er message.

J'ai re répondu car j'estimais que les arguments avancés par JBO pour justifier son choix d'utiliser les tableaux étaient tous mauvais. C'est pourquoi je les ai repris en donnant des contre arguments pour chacun d'eux. Par conséquent mes jugements sont tout sauf à l'emporte pièce dans ce cas.

Tu dois utiliser des colonnes de type tableau pour m'en vouloir autant

[=JBO=]

Bonjour,

Mon besoin est minimaliste (pas de libellé ou autres choses) et j'ai une contrainte: utiliser un seul fichier table.

Ok ?
Fin de la polémique.

D'accord avec OnePoint pour dire que vmolines en fait beaucoup trop.
_

[=JBO=]

@ mail.spam et ceux que ça intéresse,

Sur un entier long (4 octets) je peux coder 32 options, c'est bien suffisant pour mes besoins.
De toute façon, mon critère de sélection, j'allais le construire dans le code. Alors pourquoi pas coder mes options dans une valeur binaire.

Mais j'ai encore un doute par rapport à cette approche: comment l'utiliser dans un filtre ou une requête ?
(au fait je suis encore en Windev 12)

Dans une requête, je devrais me servir de la fonction ETBinaire() mais peut-elle être utilisée en SQL ?

En revanche, dans un filtre, ne crois pas que je puisse utilise l'opérateur ET binaire (&).

Je n'ai aucun recul pour les filtres et la fonction ETBinaire() en SQL.
[...]
Mais je suis curieux d'avoir le retour de tes recherches.

Alors je suis allé au bout du sujet dans la limite de ma version de Windev (WD12 ne me permet pas d'utiliser les opérateurs binaires).

On peut utiliser la fonction ETBinaire() dans une requête SQL et aussi... (grosse surprise pour moi ) dans une condition de filtre !

L'avantage de ETBinaire() dans une requête SQL, c'est qu'on peut passer en argument une valeur constante, une valeur calculée ou une rubrique.
Mais le passage d'un paramètre de requête ne fonctionne pas (aucun enregistrement n'est sélectionné).

Exemple SQL

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT * 
FROM MON_FIC
WHERE WL.ETBinaire(N_OPTIONS_BIN,1+2)<>0

La grosse surprise pour moi, c'est qu'il est possible d'utiliser une fonction WLangage dans une condition de filtre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

HFiltre(MON_FIC,"WL.ETBinaire(N_OPTIONS_BIN,1+2)<>0")

Apparemment, la condition d'un filtre accepte les mêmes expressions que celles d'une clause WHERE du SQL ???
_