Discussion :

[srappaille]

Bonjour,

Je suis confronté à un champ "varchar" contenant une liste de valeurs (uniquement des nombres).

Code :

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

1
2
3
4
5
6
7
8
9
+-------+-------------------+
| ID    | References        |
+-------+-------------------+
| 1     | 1,2,3,4,5,6       |
+-------+-------------------+
| 2     | 1,2,3             |
+-------+-------------------+
| 3     | 3,4,5,6           |
+-------+-------------------+

Dans mon exemple, je cherche à lister tous les IDs contenant la valeur 5. Soit 1 et 3.

Pour y parvenir, ma requête contient les lignes suivantes dans la clause WHERE :

Code :

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

1
2
3
WHERE table.references LIKE '5,%', 
OR table.references LIKE '%,5,%',
OR table.references LIKE '%,5'

Est-ce qu'il n'y aurait pas qqchose de plus simple et de moins énergivore pour comparer une valeur à une liste stockée dans un champ (genre "listfind()" ou autre) ?

Bien à tous,

Serge

[SQLpro]

Non, car en stockant ainsi vos données vous violez la première forme normale :
http://sqlpro.developpez.com/cours/standards/#L2.2

Dès lors vos requêtes seront compliquées à écrire et totalement anti performantes.

Le seul moyen efficace est de respecter ce que sont les bases de données relationnelles, notamment en appliquant à la lettre les formes normales au moins jusqu'à la 3e

A +

[srappaille]

Bonjour,

Je comprends mais malheureusement, ce que l'on me met sous la dent n'est pas forcément créé dans les formes de l'art.

Au moins je sais qu'il est inutile de chercher une solution de ce côté.

Merci pour votre réponse.

Bien cordialement,

[SQLpro]

Comme disent les amerloques : garbage in, garbage out, qui peut se traduire par :
si tu as de la merde en entrée, tu auras de la merde en sortie !

A +

[Philippe Robert]

Comme disent les amerloques : garbage in, garbage out, qui peut se traduire par :
si tu as de la merde en entrée, tu auras de la merde en sortie !

A +

C'est tout à fait vrai. Mais bien souvent, on doit gérer la merdre des autres. Il est quasi impossible a un DBA de rectifier un modèle de données sans adapter les applications qui en font usage, parceque les développeur n'a pas le temp ou n'est plus là.

[SQLpro]

Oui et non : la solution est de faire un refactoring avec des tables propres, mais de monter une vue qui correspond à l'ancienne table (même non) avec des trigger INSTEAD OF INSERT, UPDATE, DELETE.

A +

[Philippe Robert]

Oui et non : la solution est de faire un refactoring avec des tables propres, mais de monter une vue qui correspond à l'ancienne table (même non) avec des trigger INSTEAD OF INSERT, UPDATE, DELETE.

A +

Cela permet de faire évoluer le modèle de données, mais par-contre des trigger doivent être mis en place afin de maintenir une structure obsolète. A mon avis cela dégrade les performances et complique la maintenance opérationnelle des applications qui utilisent d'ancienne structure de données. L'idéal serait d'apater les applications concernées.