Discussion :

[Sylv_62]

Bonjour,

Je vais devoir construire une requ�te dans laquelle je dois v�rifier si un champ contient un terme.
Forc�ment, la premi�re id�e serait la suivante pour v�rifier cette clause :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
WHERE LOWER(champ) LIKE '%terme%'

Je pr�cise que le mets le Lower car le terme que je vais chercher peut �tre pr�c�d� et/ou suivi d'autres mots (le cauchemar de la recherche de mots dans un champ libre, en somme).

Cependant, j'ai d�j� entendu que le LIKE n'�tait pas fou en termes de performances (puisqu'� chaque enregistrement il va devoir parcourir toute la cha�ne de caract�res � la recherche du terme, et d�caler d'un caract�re � chaque fois).
Donc je voudrais savoir s'il existe une alternative � LIKE, qui me permettrait d'avoir une r�ponse aussi fiable � ma requ�te, en consommant moins de ressources � l'ex�cution (je sais d'avance qu'une fois la requ�te finalis�e elle risque d'�tre ex�cut�e de fa�on cyclique, par exemple mensuellement).

J'ai commenc� � chercher un peu, et je suis tomb� sur la fonction ilike qui serait insensible � la casse, ce qui me permettrait la simplification suivante :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
WHERE champ ILIKE '%terme%'

Est-ce meilleur que la combinaison LOWER + LIKE?

Est-ce que les habitu�s du SQL (en particulier SQL Server, pour mon cas) connaissent une m�thode plus efficace?

Merci d'avance pour vos conseils

(petit edit pour les majuscules, histoire de faire propre)

[Sylv_62]

Je pense avoir trouv� en parall�le : SQL Server accepte la fonction CONTAINS dans une clause WHERE.

Je vais tester avec LOWER pour pouvoir g�rer tous les cas (terme, Terme ou TERME) :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
WHERE CONTAINS(LOWER(champ), 'terme')

Je reviendrai ici dire si �a fonctionne comme j'attends.

[escartefigue]

Quelle que soit la solution, une fonction (telle que LOWER()) sur la colonne (et non pas sur le "champ") compromet l'usage des index, il en va de m�me avec une recherche LIKE (%chaine%).
Donc si la table est volumineuse, les recherches seront lentes, voire tr�s lentes.
Si le volume est important et les recherches fr�quentes, un index full text est � envisager

[SQLpro]

LOWER ne sert a rien si votre colonne est en collation CI. V�rifiez cela avec la vue INFORMATION_SC HEMA.COLUMNS.

CONTAINS ne peut �tre utilis� que si vous avez activ� la recherche en indexation textuelle (fulltext search) :
1) le module FULLTEXT est-il install� dans les services
2) avez vous d�fini un espace d'indexation textuel ? CREATE FULLTEXT CATALOG
3) avez vous cr�� un index textuele ? CREATE FULLTEXT INDEX
3.1) et quel est son mode d'alimentation (au fil de l'eau, en bacth dans l'Agent SQL ou manuel) ?
4) vous ne pouvez chercher que par terme pur ou terme finissant par...
5) si vous voulez chercher que par terme commen�ant par... il faut ajouter une colonne calcul�e persistante REVERSE et la mettre dans l'index textuel
6) si vous voulez cherches des termes avec LIKE '%toto%' lisez l'article que j'ai �crit � ce sujet (index rotatifs)

A +

[Sylv_62]

Quelle que soit la solution, une fonction (telle que LOWER()) sur la colonne (et non pas sur le "champ") compromet l'usage des index, il en va de m�me avec une recherche LIKE (%chaine%).

Pour le coup (l'ERP qui utilise cette base de donn�es a �t� install� avant mon arriv�e dans l'entreprise), je ne sais pas si la table contient des index.
Et je n'irais pas modifier la structure de la BDD, on a trop besoin de l'ERP

Donc si la table est volumineuse, les recherches seront lentes, voire tr�s lentes.
Si le volume est important et les recherches fr�quentes, un index full text est � envisager

� date, un peu plus de 7 000 lignes. Et c'est amen� � grossir.
Certains trouveront peut-�tre que c'est un volume faible, mais je m'interrogeais d�j� sur les performances avec LIKE, sachant que le nombre de lignes n'est pas fig�.

[Sylv_62]

SQLPro, pour vous r�pondre je n'ai que la r�ponse � la question 5 pour le moment.
J'aurais pr�f�r� pouvoir rechercher par terme commen�ant par. J'aurais d�j� pu utiliser SUBSTRING pour pouvoir v�rifier si les x premiers caract�res de la colonne �galent � terme.
Mais j'ai plusieurs exemples de lignes de r�sultats (� prendre en compte) qui contiennent terme ou Terme sans commencer par Terme ou terme.

De m�me, j'ai des occurrences (toujours � prendre en compte) de terme, Terme et TERME.
C'est pour �a que je souhaite pouvoir insensibiliser la clause � la classe, j'ai un minimum de 3 fa�ons diff�rentes (d'un point de vue SQL) d'enregistrer le m�me mot-cl� (du point de vue utilisateur).

De plus, comme dit � escartefigue, j'ai les mains li�es sur la structure de la BDD (on ne parle pas d'un site web auto-h�berg� sur lequel on peut changer ce qu'on veut et reconstruire tout si �a pose probl�me) sans avoir tout l'historique.

Je vais tout de m�me creuser les sujets de la collation CI et des index rotatifs.
Vu que je ne connais ni l'un ni l'autre, c'est l'occasion d'apprendre.

[SQLpro]

La collation permet de g�rer le comportement des chaines de caract�res au regard de la casse ou des caract�res diacritique (accents, ligature...) sans changer quoi que ce soit ni � la structure de la base ni aux donn�es. Il faut utiliser l'op�rateur COLLATE...

Le fait d'jouter des index � une base est quelque chose "d'obligatoire" sinon vous n'obtiendrez jamais de bonnes performances. C'est comme le fait de mettre du carburant dans une voiture pour avancer. Le constructeur de la voiture ne peut en aucun cas vous le reprocher, car c'est du domaines de la bonne gestion de votre v�hicule.... (sinon a quoi servirait-il ?). L'indexation c'est le carburant dont la base � besoin pour aller vite.... Une voiture n'a pas besoin de carburant pour avancer. Il suffit de la pousser !
Je m'�tonne que ces notions vous soient inconnues.. En effet votre titre est "Administrateur syst�mes et r�seaux". Vous devriez �tre au courant de ce genre de choses...
L'op�rateur CONTAINS n�cessite la cr�ation d'index fulltext. Il ne peut fonctionner sans cela. Pour cr�er un index fulltext il faut que le service fulltext soit install� et activ�. C'est du domaine de l'admin SQL Server et non de l'�diteur. Donc vous pouvez le faire sans probl�me !

A +

[Sylv_62]

Merci pour l'op�rateur COLLATE, qui va me permettre d'avoir une insensibilit� � la casse.

De plus, votre r�ponse m'a permis de constater que le service fulltext est d�j� pr�sent et d�marr� sur mon serveur SQL, je vais donc pouvoir m'atteler � la cr�ation du bon index.

Je me permets toutefois un d�saccord avec votre analogie sur le monde de la voiture.
Le carburant est un indispensable au fonctionnement du moteur = sans carburant, �a revient � mes yeux � un serveur SQL sans donn�es : une coquille vide.
Je comparerais plut�t les index aux pneus de la voiture.
Une base de donn�es sans le bon index, �a va �tre comme un SUV en pneus �t� + �conomies d'�nergie us�s dans la neige ou une voiture sportive avec des pneus typ�s �conomies d'�nergie sur un circuit : �a va finir par passer, mais �a sera lent, voire flou ou dangereux. Alors qu'avec le bon index, �a sera comme si on mettait des pneus hiver sur notre SUV ou des pneus slick sur la sportive pour le circuit, �a passerait sans encombres (pour la neige) et tr�s vite (pour le circuit).

Je reviens sur ma m�connaissance sur les bases de donn�es, malgr� mon titre "honorifique" d'administrateur syst�mes & r�seaux, les postes par lesquels je suis pass� ont fait que j'ai eu plus souvent les mains sur du mat�riel r�seau, des postes de travail ou des serveurs d'annuaire et de fichiers que dans les bases de donn�es.
Et h�las, depuis 2 ans mes possibilit�s de cr�er des labos de test pour me former se sont r�duites, donc je viens sur le forum et je finis par me sentir ignorant sur certains domaines.

J'arr�te ma digression ici, et je m'en vais cr�er un index fulltext pour pouvoir utiliser ce CONTAINS.

[escartefigue]

Pour le coup (l'ERP qui utilise cette base de donn�es a �t� install� avant mon arriv�e dans l'entreprise), je ne sais pas si la table contient des index.
Et je n'irais pas modifier la structure de la BDD, on a trop besoin de l'ERP


� date, un peu plus de 7 000 lignes. Et c'est amen� � grossir.
Certains trouveront peut-�tre que c'est un volume faible, mais je m'interrogeais d�j� sur les performances avec LIKE, sachant que le nombre de lignes n'est pas fig�.

Un table sans index - � minima celui de la contrainte PK - est une anomalie : sans index unique, aucune contrainte d'int�grit� ne peut �tre install�e.
Or, une base sans contrainte d'int�grit� est une base dont le contenu n'est pas fiable.
Cr�er un index l� o� il est manquant ne met aucunement en p�ril la BDD, l'ajout d'index uniques manquants met souvent en �vidence des doublons, c'est l'occasion de faire du nettoyage.
Mais, en g�n�ral, dans un ERP, on n'a pas le droit de modifier quoi que ce soit sans l'accord de l'�diteur, au risque de perdre la garantie .
Il faut donc v�rifier quels sont les �ventuels index manquants, puis v�rifier aupr�s de l'�diteur ce qui peut �tre fait, quitte � l'int�grer dans une version +1 du logiciel.

7000 lignes c'est rien du tout, un table scan (sans passer par un index donc) ne prendra que quelques millisecondes tout au plus.

Et une remarque s�mantique :
"� date" est un anglicisme, en fran�ais, "� date" signifie "pourvu d'une date", par exemple "timbre � date" ou "cachet � date".
En fran�ais, il faut dire "� ce jour" dans ce contexte

[SQLpro]

...
Je me permets toutefois un d�saccord avec votre analogie sur le monde de la voiture.
Le carburant est un indispensable au fonctionnement du moteur = sans carburant, �a revient � mes yeux � un serveur SQL sans donn�es : une coquille vide.

Non, les donn�es du SGBDR ce sont les passagers... Que vous ne contr�lez pas forc�ment si vous �tes un chauffeur de taxi ou de bus (base de donn�es d'�diteur).... Si les passagers sont vos proches, c'est plus facile, car vous pouvez leur imposer de mettre tel ou tel v�tement pour rentrer dans la voiture (base de donn�es d�velopp�e en interne).

...
Je reviens sur ma m�connaissance sur les bases de donn�es, malgr� mon titre "honorifique" d'administrateur syst�mes & r�seaux, les postes par lesquels je suis pass� ont fait que j'ai eu plus souvent les mains sur du mat�riel r�seau, des postes de travail ou des serveurs d'annuaire et de fichiers que dans les bases de donn�es.
Et h�las, depuis 2 ans mes possibilit�s de cr�er des labos de test pour me former se sont r�duites, donc je viens sur le forum et je finis par me sentir ignorant sur certains domaines.

Vous n'�tes h�las pas le seul... ayant enseign� dans les �coles d'ing�nieurs, je me suis �chin� � essayer de donner un vernis de connaissance "basiques" de l'informatique... Peine perdues. Quand aux admins syst�me, je me suis toujours demand� pourquoi on ne leur enseignait jamais le fonctionnement des serveurs de bases de donn�es, de loi les plus importants ! Ils sont souvent tellement ignorant qu'il font les choses en contradiction totale pour s�curiser le serveur et avoir de bonnes performances... Cela dit, �a nous permet de vendre, fort cher, des journ�es d'intervention pour rectifier le merdier !

J'arr�te ma digression ici, et je m'en vais cr�er un index fulltext pour pouvoir utiliser ce CONTAINS.

Sagesse !

A +

[Michel.Priori]

Donc je voudrais savoir s'il existe une alternative � LIKE, qui me permettrait d'avoir une r�ponse aussi fiable � ma requ�te

oui, on peux
il suffit de faire une soustraction de chaine et de compter si on a le m�me nombre de caract�res.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

WHERE len(colonne) > len(replace(colonne, 'terme','')

Cependant, j'ai d�j� entendu que le LIKE n'�tait pas fou en termes de performances

O� avez vous entendu �a ?
Et, surtout, pourquoi l'avez cru ?

J'imagine que que vous avez fait des tests pour valider vos ou�es dires.
Pouvez vous nous faire part du protocole et des r�sultats ?

[escartefigue]

Like peut �tre performant s'il est discriminant.

Ainsi, like 'M%' sur une colonne contenant un nom ou un pr�nom n'est pas discriminant, l'index s'il existe ne sera pas pertinent et un table scan sera probablement effectu�
� l'inverse, like 'MARTIN%' est possiblement discriminant, l'usage d'un index est possible.
Par contre, si l'on recherche une cha�ne de caract�res finissant par, c'est � dire like '%chaine', les index standard (hors index rotatifs mentionn�s par Fred) ne sont pas utilisables.

[Michel.Priori]

Like peut �tre performant s'il est discriminant.

J'entends.
Mais c'est pas exactement ce qui a �t� critiqu� dans la demande initiale.

Quand on parle de performance on va parler de "qualification de l'algorithmique".
On sait tous que l'algo de "doubles boucles imbriqu�es" (nested loop) peut �tre la pire ou la meilleure des r�ponses.

Ici il est dit :

Cependant, j'ai d�j� entendu que le LIKE n'�tait pas fou en termes de performances (puisqu'� chaque enregistrement il va devoir parcourir toute la cha�ne de caract�res � la recherche du terme, et d�caler d'un caract�re � chaque fois).

D'une part je ne peut affirmer ou infirmer si effectivement l'op�rateur LIKE n'a qu'une seul algo � son actif et, auquel cas, que c'est bien celui d�crit.
D'autre part, si on a qu'une solution, elle est par d�finition : la meilleure.


Du coup je suis int�ress� par le retour d'exp�rience sur LIKE (avec ou sans index) et CONTAINS (avec index en texte int�gral) sur un lot de 7000 lignes et 1 seule colonne (dont le type nous reste inconnu).
Est-ce qu'on gagne plus de 3 secondes ? sur quelle plateforme (CPU, RAM, DD) ?

[Sylv_62]

Bonjour � tous les 3, et merci pour vos r�ponses.

Pour r�pondre (� ma fa�on un peu "d�sorganis�e", pour rester poli) mais de fa�on chronologique par rapport � vos messages :

- D'apr�s ce que je viens de voir dans SQL Server Management Studio, il existe bien des index pour cette table, dont un sur la cl� primaire.
C'est un point rassurant, m�me si l'index dont j'avais besoin n'y est pas.

- Mes excuses pour l'anglicisme, habituellement je pr�f�re parler en Fran�ais, mais � force de lire ou d'entendre une expression on peut finir par l'int�grer � sa fa�on de parler...

- Pour r�pondre � SQLpro, sur le sujet de la formation des administrateurs syst�mes, ayant une exp�rience en centre de formation �galement (m�me si je n'�tais pas formateur), j'ai l'impression que dans l'imaginaire de beaucoup de gens le m�tier d'administrateur syst�mes et celui d'administrateur de bases de donn�es sont tr�s diff�rents.
Cela peut s'accentuer aussi avec le fait que, pour ceux qui choisissent de suivre leur formation en alternance, la majorit� vont dans de grosses structures ou des ESN, ce qui provoque un "fractionnement" suppl�mentaire des t�ches.
Il me para�t �galement possible (m�me si je peux me tromper) que certains administrateurs syst�mes pensent uniquement disponibilit� et s�curit� des ressources, en pensant que les utilisateurs vont s'adapter � leurs r�gles. M�me si je pense (d'autant plus dans le contexte g�opolitique actuel) qu'il reste tr�s important d'avoir des r�gles et une grosse dose de s�curit� informatique, il ne faut pas oublier que l'informatique est en g�n�ral un service et que �a doit �tre pratique pour les utilisateurs.

- j'ai bien aim� l'analogie des donn�es avec les passagers, et je pousserais m�me l'id�e un peu plus loin en disant que dans le cas d'une BDD li�e � un ERP on ne choisit pas sa structure.
Et, pour le coup, c'est l� que je vois les contraintes li�es � l'utilisation d'un ERP...

- pour r�pondre � Michel.priori, ma requ�te n'�tant pas finie, je n'ai fait aucun test, par cons�quent je ne peux pas donner de protocole de test.
L'id�e selon laquelle l'op�rateur LIKE ne serait pas la meilleure r�ponse pour avoir rapidement un r�sultat fiable me vient � la fois de recherches internet (m�me si je suis conscient que tout ce qui est sur internet n'est pas forc�ment � prendre pour argent comptant), de cours de bases de donn�es (qui datent d'entre 2006 et 2008 cela dit, une �poque o� on �crivait les requ�tes sur papier pour les contr�les et dont mes souvenirs peuvent s'estomper) et pour finir d'une fa�on de penser li�e au contexte dans lequel je pensais utiliser l'op�rateur LIKE.
Pour r�sumer, j'�tais parti dans l'id�e que si je cherchais � utiliser une clause du type WHERE champ LIKE 'terme%', �a revenait � v�rifier uniquement les X premiers caract�res dans champ pour les comparer � terme, et que donc cela pouvait rester "performant" (sous-entendu rapide, tout en renvoyant un r�sultat fiable).
Cependant, dans mon contexte, je dois rechercher %terme% car terme pouvait �tre plac� n'importe o� dans le champ (qui est un nvarchar(255) par ailleurs). Ma compr�hension �tait donc que le LIKE allait devoir chercher � chaque fois dans la cha�ne de caract�res si terme �tait pr�sent, en partant du d�but et en d�calant � chaque fois d'un caract�re pour rev�rifier la correspondance avec terme.
En l'absence de test norm�, je comprends toutefois que mon ressenti puisse �tre fauss�, et je serais moi aussi curieux � l'occasion de faire des tests si je peux en prendre le temps.

Place maintenant � la partie "rigolote" du sujet, pour vous donner les suites de cette demande sur laquelle vous avez pris le temps de r�ponse.
J'ai voulu cr�er le fameux index fulltext conseill� par SQLpro : impossible!
Les acc�s � la base de donn�es (qui sont g�r�s par l'�diteur de l'ERP) ne me permettent pas de cr�er un index.
Donc, � ce jour, je n'ai toujours pas d'index fulltext - et donc toujours pas la possibilit� de tester un hypoth�tique �cart de performances des requ�tes.

Cependant, j'ai contourn� mon probl�me gr�ce � une autre table de la base de donn�es.
Et dans cette table, j'ai une colonne (de type nvarchar(10) dont le contenu est "restreint" par un choix dans une liste d�roulante de l'ERP.
Je n'ai plus qu'� faire une clause WHERE ResourceType (la colonne s'appelle ainsi) IN ('choix A', 'choix B)' pour isoler les donn�es dont j'ai besoin.

Je passe donc ce sujet en r�solu, si �a peut d�j� permettre � d'autres de trouver plus facilement l'info concernant les index fulltext.
Et � l'occasion, si j'ai un peu de temps pour tester les deux m�thodes (celle "en production" avec ma colonne ResourceType et celle avec champ LIKE '%terme%'), je reviendrai donner un peu plus de r�sultats sur le comparatif de performances des requ�tes.

[Michel.Priori]

Bonjour � tous les 3, et merci pour vos r�ponses.

Merci � toi pour ce retour !


remarque sur le choix des types :
Utiliser le type NVARCHAR(10) pour alimenter une liste d�roulante n'est pas forcement un choix judicieux, � voir l'occupation de la table en nombre de page.
Les types N imposent un stockage UNICODE (UTF16 pour SQLserver) alors que sans, on est en ASCII ; 2 ou 4 octets par caract�res au lieu de 1 ; D�terminer si un caract�re est cod� sur 2 ou 4 octets = du calcul, certes facile, mais du calcul en plus ; sans compter qu'un seul octet par caract�re est tr�s probablement suffisant en Europe.
Varchar(n) utilise 2 octets en tant que caract�res de contr�le pour signifier la fin du stockage de la valeur ; pour les valeurs faibles de n il est souvent rentable de choisir Char(n).
Tout �a �tant � contre balancer avec le nombre de pages de Ko r�ellement occup� par la table ; si elle ne fait qu'une page, difficile de faire mieux
Les outils actuels qui sont radicalement orient� Web et internationalisation, il est difficile de faire comprendre que la logique de traitement n'est pas celle du stockage et que vouloir internationaliser une r�f�rence qui ne sera jamais �crite en cyrillique, h�breu ou en mandarin, est dispendieux.

Maintenant que tu as une fa�on rationnelle de r��crire ta requ�te, �tudie le plan d'ex�cution de celle ci et compare le � celle int�grant le LIKE

[SQLpro]

...j'ai l'impression que dans l'imaginaire de beaucoup de gens le m�tier d'administrateur syst�mes et celui d'administrateur de bases de donn�es sont tr�s diff�rents.

Deux mondes tr�s diff�rents et malheureusement les ing� syst�me appliquent aux SGBDR les principes qu'ils ont appris du syst�me et qui sont en g�n�ral en contradiction totale avec les principes � adopter avec les SGBDR. Pour la petite anecdote, il y a une quinzaine d'ann�e, un �diteur avec lequel je travaillais, faisait des application de texte-mining. Dans ces cas l� la base de donn�es comprend 90% d'index (tr�s particulier) et seulement 10% de donn�es bruts. Compte tenu du volume de la future base, l'�diteur me demande la configuration du serveur et je leur dit 8 c�urs et 64 Go de RAM (les SGBDR traitent es donn�es uniquement en RAM).
Un peu plus d'un mois apr�s je suis appel� par l'�diteur qui me dit que chez ce client c'est tr�s lent.... Il me propose de voir ce qui se passe et nous convenons de pr�voir une journ�e d'audit � 1 000 �... Je lui dit que si c'est de la faut du client final c'est le client final qui devra payer. Tout le monde est d'accord.
Au bout de 5 minutes je constate que le serveur n'avait que 4 Go de RAM ! Je dit � l'ing�nieur syst�me de mettre 64 Go de RAM sur le serveur. Il me r�pond "c'est pas le probl�me... Le serveur SQL fait beaucoup trop d'IO (Input/output c'est � dire Entr�e-Sortie, ce qui signifie des acc�s disque en lecture input et �criture output pour alimenter la RAM). Je lui r�pond que c'est justement pour cela que j'exige 64 Go de RAM... Il me traite d'idiot... Je me f�che tout rouge et demande � parler � son sup�rieur qui r�gle le probl�me dans l'heure... Et � miracle, plus d'IO.... Toutes les donn�es �taient en m�moire ! Ce cr�tin (h�las employ� d'une grosse boite...) ne sachant pas comment fonctionne un SGBDR pensait que cela fonctionnait comme un tableur ou tout autre logiciel bas de gamme..... Nous avons sut apr�s qu'il mettait toujours 4 Go de RAM quelque soit le serveur... ! (un peu comme si sur une formule 1 on mettait des pneus de v�lo.... !)

L'id�e selon laquelle l'op�rateur LIKE ne serait pas la meilleure r�ponse pour avoir rapidement un r�sultat fiable me vient � la fois de recherches internet (m�me si je suis conscient que tout ce qui est sur internet n'est pas forc�ment � prendre pour argent comptant), de cours de bases de donn�es (qui datent d'entre 2006 et 2008 cela dit, une �poque o� on �crivait les requ�tes sur papier pour les contr�les et dont mes souvenirs peuvent s'estomper) et pour finir d'une fa�on de penser li�e au contexte dans lequel je pensais utiliser l'op�rateur LIKE.

Malheureusement, non seulement Internet est farci d'articles plus ou moins stupide intelligent, mais les moteurs de recherche index par popularit� et non pas par qualit� ni intelligence. Donc, � moins de conna�tre d�j� le sujet, vous trouverez en premier lieu les articles les plus d�biles, stupide et approximatifs.... De plus, la plupart de ces article sont �crit en r�f�rence aux SGBDr les plus populaire (MySQL, MariaDB, SQLlite parfois PostGreSQL...) qui sont tr�s loin d'voir les performances de SQL Server. Dans un de mes audit pour un grand compte de la t�l�phonie, je disais "tant que les d�veloppeurs seront autoform�s sur Internet, il resteront mauvais tout simplement par ce que les moteurs de recherche indexent par popularit� et que les poils de cul de Paris Hilton sont plus populaire que la philosophie de Marx ou d'Engels...."

Pour information j'ai arr�t� de donner des cours sur le SQL, les SGBDR et la mod�lisation de donn�es dans les �coles d'ing� (EPITA, ISEN, CESI...) en 2015 parce que les �l�ves s'en foutaient et que c'�tait la mode du NoSQL.... Mais vous pouvez toujours acheter mes livres ou commencer par vous former avec le nouveau que j'ai commenc� � �crire :
https://sqlpro.developpez.com/livre/...le-langage-sql

Bref, ne lisez pas toutes les conneries d'Internet. Choisissez vos sites, r�f�rencez en donc quelques uns comme developez.com.

D'autant qu'en mati�re de LIKE SQL Server est un des rares SGBDR � savoir optimiser les requ�tes LIKE '%abacadabra%'. Faites le test suivant sur une grande table ;

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

SELECT * FROM Matable WHERE MaColonne LIKE '%ert%';

Ne lancez pas la requ�te mais allez dans SSMS voir le plan de requ�te et lire dans la bulle jaune le nombre de ligne estim�.

lancez alors la requ�te et comparez le nombre de lignes estim�es et le nombre de ligne du r�sultat et vous verrez que l'estimation est assez bonne !

Or ce param�tre (nombre de ligne = cardinalit�) est l'�l�ment le plus important pour l'optimiseur qui gr�ce � la valeur obtenue va adapter les algorithmes et le s�quencement des �tapes de la requ�te pour optimiser le temps de traitement....

A +

[escartefigue]

Bonsoir

(m�me si je suis conscient que tout ce qui est sur internet n'est pas forc�ment � prendre pour argent comptant), .

C'est un fait.
Et pire encore, l'intelligence artificielle, qui compile tout ce qu'on trouve sur internet pour en d�duire, statistiquement parlant, la r�ponse appropri�e, en d�duit parfois (le plus souvent ?) que la r�ponse la plus fr�quente est la meilleure.
Je me suis amus� � soumettre � ChatGPT un exercice basique de mod�lisation de bases de donn�es, en l'occurrence un mod�le client, commande, ligne de commande et article.
Autant dire l'enfance de l'art.
Malgr� un �nonc� bien d�taill� et plusieurs corrections successives de ma part cons�cutives aux r�ponses erron�es de l'IA, il a fallu de nombreuses it�rations pour obtenir une r�ponse loin du MCD optimal.