Discussion :

[cladoo]

Bonjour,

Je ne sais pas très doué en SQL...je ne sais pas s'il est possible de faire cela sous Windev :

J'ai un table A (ID, liste)
> liste est une rubrique de type chaine qui contient par exemple "A1,B1,D3,A7..."

Est-il possible via une Requête de récupérer les enregistrements dont liste contient par exemple les éléments:
- B1 et D3
- B1 ou A7
etc...

J'ai bien pensé à utiliser l'opérateur IN avec un code du style :

Code :

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

1
2
3
 
SELECT * FROM A WHERE
Liste  IN 'B1' AND Liste IN 'D31'

qui bien entendu ne fonctionne pas. Le problème est que Liste contient un ensemble de chaînes séparées par des , et pas une chaîne unique, comment faire pour tester chacune ?

Existe-t-il un moyen efficace sous Windev de faire celà ?
Je précise que je suis en HyperFile C/S

Merci

[cladoo]

Bon, je me réponds tout seul, en utilisant :

Code :

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

1
2
3
 
SELECT * FROM A WHERE
Liste LIKE '%A1%' OR Liste LIKE '%B2%'

ça marche.

S'il existe une meilleure solution, ma question court toujours

[tatayo]

Bonjour,
Tu peux utiliser like:

Code SQL :

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

1
2
3
 
SELECT * FROM A WHERE
(Liste like '%B1,%' or liste like '%B1') AND (Liste like '%D31,%' or liste like '%D31')

Tatayo.

[cladoo]

Merci Tatayo tu confirmes mon idée

[vmolines]

Même si la solution "marche", on ne stocke pas une multitude de valeur dans une colonne mais une seule. La requête est bancale, pas performante et difficile à maintenir.

[cladoo]

Je suis d'accord sur le principe, mais là je peux difficilement faire autrement, j'ai besoin de stocker les balises rencontrées dans un fichier, elles peuvent être toutes présentes, comme aucune, comme un certain nombre et ces mêmes balises ne sont pas figées, de nouvelles apparaissent souvent, donc difficile de les prévoir ...

Bref, j'ai aussi pensé à passer par un fichier de variables mais je ne suis pas séduit.

Une autre idée ? (sachant que rien n'est encore figé)

[vmolines]

Avec une modélisation normale, si vous deviez représenter que l'entité A peut avoir des balises :

A = {A_ID, ...}
BALISE = {BALISE_ID, BALISE_CODE}
A_BALISE = {#A_ID, #BALISE_ID}

Quand vous parsez un fichier :

- Ajout des balises qui n'existent pas dans la table BALISE
- Ajout d'une ligne dans la table A (qui a l'air de matérialiser un fichier)
- Ajout des lignes dans la table A_BALISE pour indiquer que A possède des balises.

Retourner les lignes de A qui disposent des balises B1 et D31 :

Code :

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

1
2
3
4
5
6
7
8
9
10
SELECT 
	A_BALISE.A_ID, 
	COUNT(A_BALISE.BALISE_ID)
FROM A_BALISE 
	INNER JOIN BALISE 
		ON A_BALISE.BALISE_ID = BALISE.BALISE_ID 
WHERE BALISE.BALISE_CODE IN ('B1', 'D31')
GROUP BY 
	A_BALISE.A_ID
HAVING COUNT(A_BALISE.BALISE_ID) = 2

Les tables sont minimales, l'utilisation des index possible et les traitements simplifiés.

Et merci aux participants pour les évals négatives sur ma critique de votre modélisation, je suis comblé

[cladoo]

Cette solution est en effet tout à fait viable. Je vais y réfléchir.
Merci

[vmolines]

Vu votre précédente interrogation sur les performance et la volumétrie, je vous invite à tester les deux modélisations/requêtes avec une volumétrie de 100000 fichiers et 5000 balises.

Je serais heureux de voir les résultats pour voir si je mérite ou non ma critique .

Projetez vous et réfléchissez à la tête des requêtes pour analyser les données par balise avec la première modélisation. Je vous souhaite bien du plaisir.

[cladoo]

Il est clair que ma "solution" ne tient pas la route face à la votre, c'était une solution dite de facilité, qui j'en conviens ne respecte pas du tout le principe de modélisation.

Encore une fois, je ne suis pas doué en SQL, je ne suis même pas informaticien, donc vos conseils sont plus que bienvenus.