Discussion :

[bpdelavega]

J'aimerai faire une requête utilisant les expression régulière mais je connais pas la syntaxe exacte : j'ai mis ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
SELECT DISTINCT 
                      ISNULL(CIV_SHORT, '') + ' ' + ISNULL(RES_NOM2, '') + ' ' + ISNULL(RES_NOM, '') AS CLIENT_NOM, 
                      RES_PAYSID AS CLIENT_PAYS, 
					  Nom_Hotel AS CLIENT_HOTEL, 
					  RES_DATEARR AS HOTEL_DATE_ENTREE, 
					  RES_DATEDEP AS HOTEL_DATE_SORTIE, 
                      RegexSelectAll(EMAIL, "^[a-zA-Z0-9\-_]+[a-zA-Z0-9\.\-_]*@[a-zA-Z0-9\-_]+\.[a-zA-Z\.\-_]{1,}[a-zA-Z\-_]+" )AS CLIENT_EMAIL, 
					  CAN_DESC AS ORIGINE_RESERVATION, 
					  NB_JOURS
FROM         dbo.liste_departs_FrontRes_Generiques
WHERE     (NB_JOURS <= 420) AND (Nom_Hotel <> 'Mathis Elysees Hotel')
ORDER BY NB_JOURS DESC

Mais cela ne fonctionne pas. D'avance merci pour votre aide.

[Glouferu]

Bonjour,

Personne n'a encore répondu donc je vais tenter de t'aider au mieux.
Chez moi la fonction me retourne : 'RegexSelectAll' is not a recognized built-in function name.
Visiblement ce n'est pas une fonction SQL Server ou alors utilisable avec d'autres librairies, je ne sais pas.

Les expressions régulières s'utilisent dans tes prédicats :

Code :

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

WHERE EMAIL like '% ton_expression_régulière %'

Pour plus d'info sur la commande like : http://msdn.microsoft.com/fr-fr/library/ms179859.aspx

Maintenant, pour essayer de nettoyer ou mettre en forme ton champ EMAIL, j'utiliserais les fonction

Code :

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

SUBSTRING, REPLACE, UPPER, LEN

etc ...


En espérant avoir pu t'orienter dans ta recherche.
Cdt,

[rudib]

Bonjour,

en effet, SQL Server ne supporte pas les expressions rationnelles, tu as juste un LIKE à disposition, avec une syntaxe sommaire.
Tu peux faire des expressions rationnelles en développant toi-même une fonction en .NET et en l'intégrant dans SQL Server. Attention, les performances ne seront pas terribles.

Tu as ici un article pour t'aider.

[bpdelavega]

Merci à tous pour vos réponses : je ne peux pas rajouter de fonction .NET, d'une je ne sais pas faire, et de deux je n'ai pas les droits.

En fait je voulais juste faire en sorte que je puisse bien avoir des adresses emails valides pour mon emailing : en fait je fais le traitement sur deux BD, une sous Oracle et l'autre sous SQL Server. J'ai fait la manip sur Oracle et c'est bien pratique de traiter l'info en amont directement dans la requête et je voulais faire pareil sur Sql Server : il y a un t'il un moyen via un script SQL genre un trigger ?

[SQLpro]

comme indiqué, il faut passer par une fonction SQL CLR développée en .net. MS en fournit une toute faite.

Par sécurité, la config du serveur interdit l'utilisation de SQL CLR, mais il suffit de reconfigurer cela par :

Code :

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

1
2
3
4
exec sp_configure 'clr enabled', 1;
go
reconfigure
go

A +

[zinzineti]

Permettez-moi de rebondir sur ce sujet.
Actuellement la plupart des SGBDs ont intégré de façon native la gestions des expressions régulières. Après hésitation ORACLE l'à finalement introduit depuis sa version 10G. Et aujourd’hui en 2011 MS n'a pas jugé bon d'intégrer ces fonctions dans son SGBD ! et demande aux utilisateurs de créer des fonctions CLRs. Donc de faire un peu de code .NET et de le déployer dans SQL Server ! Qu'est ce que sa coûte à MS t'intégrer de façon native : la gestion des expressions régulières ?

[Glouferu]

Permettez-moi de rebondir sur ce sujet.
Actuellement la plupart des SGBDs ont intégré de façon native la gestions des expressions régulières. Après hésitation ORACLE l'à finalement introduit depuis sa version 10G. Et aujourd’hui en 2011 MS n'a pas jugé bon d'intégrer ces fonctions dans son SGBD ! et demande aux utilisateurs de créer des fonctions CLRs. Donc de faire un peu de code .NET et de le déployer dans SQL Server ! Qu'est ce que sa coûte à MS t'intégrer de façon native : la gestion des expressions régulières ?

Surtout que gérer cela en natif éviterait les problèmes de perfs !

[zinzineti]

Surtout que gérer cela en natif éviterait les problèmes de perfs !

Espérons que la prochaine version de SQL SERVER prenne en compte ce besoin. Et ce n'est pas le seul ...

[SQLpro]

Vous avez tort, car une implémentation SQL CLR est plus rapide que ce que pourrait faire du Transact SQL. Pour être efficace cela devrait être réalisé sous forme de DLL C... Ce qui revient à utiliser le SQL CLR, mais avec l'avantage considérable du code "managé" (géré en .net) qui est bien plus sécurisé que le C !!!
En effet en cas de mauvaise conduite de la DLL, il n'y a pas contamination de l’existence de SQL Server, ce qui est possible avec un langage comme C ou C++

C'est pourquoi il est beaucoup plus sûr et rationnel de faire cela en .net.

Ceux qui vous interdisent d'utiliser SQL CLR sont des imbéciles qui n'ont rien compris de l'intérêt de .net dans ce cas de figure...

En sus sachez que SQL Server utilise .net sans vous le dire pour le type Hierrachyid comme pour les types geometry et geography du SIG intégré depuis la version 2008...

A +

[bpdelavega]

Merci beaucoup pour vos réponses, vraiment chapeau bas pour votre expertise : bon du coup, dans mon cas je fais quoi, en vous rappelant que je ne connais pas du tout .NET et j'ai travaillé il y a bien longtemps sur SQL Server, et ça commence à dater maintenant, pour être sûr que je remonte bien des emails et pas autre chose ?

[SQLpro]

Microsoft vous donne un DLL toute faite. Il n'y a qu'a l'intégrer sous forme d'Assembly en faisant
CREATE ASSEMBLY...
Puis à partir de cette assembly créer la fonction
CREATE FUNCTION ...
AS EXTERNAL NAME <method_specifier>

A +

[zinzineti]

Vous avez tort, car une implémentation SQL CLR est plus rapide que ce que pourrait faire du Transact SQL. Pour être efficace cela devrait être réalisé sous forme de DLL C... Ce qui revient à utiliser le SQL CLR, mais avec l'avantage considérable du code "managé" (géré en .net) qui est bien plus sécurisé que le C !!!
En effet en cas de mauvaise conduite de la DLL, il n'y a pas contamination de l’existence de SQL Server, ce qui est possible avec un langage comme C ou C++
C'est pourquoi il est beaucoup plus sûr et rationnel de faire cela en .net.

Qu'est ce ça coûte à MS t'intégrer de façon native la gestion des expressions régulière dans son SGBD ?

Ceux qui vous interdisent d'utiliser SQL CLR sont des imbéciles qui n'ont rien compris de l'intérêt de .net dans ce cas de figure...

Si MS introduit la gestion des expressions régulières dans son SGBD alors pour des besoins spécifiques, on ne sera pas obliger de créer d'abord la fonction CLR ( donc du code .NET) dans visual studio ou autres ...
Ce qui constitue à mon avis une perte de temps, donc perte de productivité...

En sus sachez que SQL Server utilise .net sans vous le dire pour le type Hierrachyid comme pour les types geometry et geography du SIG intégré depuis la version 2008...

D'où ma question initiale : Qu'est ce ça coûte à MS t'intégrer de façon native la gestion des expressions régulière dans son SGBD ?

[SQLpro]

1) il n'est pas possible d'utiliser toutes les fonctionnalité d'une REGEX classique dans un SGBDR. En effet une REGEX comme GREP est dédié à la recherche d'éléments littéraux dans des fichiers et non dans des tables.
2) certaines possibilités des REGEX classiques n'ont pas de sens dans une recherche dans une table car une table n'est pas constitué que de littéraux... Il y a aussi des dates, des chiffres.
3) pour ce faire la norme SQL a précisé une fonction particulière de nom SIMILAR qui est décrite dans mon bouquin sur SQL. Elle n'est aujourd'hui implémenté que très rarement !

Conclusion : vous seriez frustré de n'avoir la possibilité que d'un seul choix de fonction d'expression régulière, alors que cela dépend des cas de figure...

A +

[zinzineti]

1) il n'est pas possible d'utiliser toutes les fonctionnalité d'une REGEX classique dans un SGBDR. En effet une REGEX comme GREP est dédié à la recherche d'éléments littéraux dans des fichiers et non dans des tables.

Je ne suis pas d'accord. Car ORACLE ouvre toutes les fonctionnalités d'une REGEX classique.

REGEXP_LIKE(mycolonne, pattern)
REGEXP_SUBSTR(mycolonne, pattern, position, occurrence)
REGEXP_REPLACE(mycolonne, pattern, remplacement, position, occurrence)
REGEXP_INSTR(mycolonne, pattern, position, occurrence, return)

avec ces fonctions il n'y a plus de limite ....car on peut mettre en oeuvre toutes les possibilités avec les pattern

2) certaines possibilités des REGEX classiques n'ont pas de sens dans une recherche dans une table car une table n'est pas constitué que de littéraux... Il y a aussi des dates, des chiffres.

Tout dépend du besoin. Par exemple lorsqu'il s'agit de mettre en oeuvre le routage (routage basé sur des templates) et la gestion des emails on se rend compte de l'utilité des expressions régulières étant donné que ces emails sont stockés dans des tables.

3) pour ce faire la norme SQL a précisé une fonction particulière de nom SIMILAR qui est décrite dans mon bouquin sur SQL. Elle n'est aujourd'hui implémenté que très rarement !

Conclusion : vous seriez frustré de n'avoir la possibilité que d'un seul choix de fonction d'expression régulière, alors que cela dépend des cas de figure...

A +

je pense que sur ce point SQL SERVER est un peu en retard

Désolé bpdelavega tu vois je laisse de côté ta question pour blablater

je vais me rattraper sur un autre sujet

A+

[bpdelavega]

Non au contraire, merci de m'avoir répondu zinzineti, je vais essayer de faire ce que vous m'avez dit, je vous fais un retour dès que possible, j'ai dû interrompre ces travaux pour en faire d'autres, donc j'ai pas encore eu le temps de m'y remettre.

[Ptit_Dje]

Mon ami Google m'a repondu a la question "regex sql server clr":
http://msdn.microsoft.com/en-us/magazine/cc163473.aspx - Lien 1
http://www.simple-talk.com/sql/t-sql...er-by-example/ - Lien 2.

Je pense qu'avec un peu de lecture et de copier coller, il sera facile d'integrer les regex a votre DB.