Discussion :

[QuelJean]

Bonjour à tous,

Je cherche à tester des numéros de téléphone dans plusieurs tables et dans plusieurs champs.

J'ai besoin de créer un programme que revoie un booléen 0/1 en fonction de la présence d'un indicatif dans le numéro de téléphone.

Exemple : 0655443322 > résultat = 0
0033655443322 > Résultat =1

Pour ce faire, j'ai une table contenant la liste des indicatifs qui m'intéresses.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
 
CREATE TABLE [QDD].dbo.QDD_Liste_Indicatifs_telephone  (
	[Id] BIGINT NOT NULL IDENTITY(10000000000,1) ,
	[Valeur] NVARCHAR(20) , 
	[Taille] NVARCHAR(20) , 
	[Region] NVARCHAR(50) 
	CONSTRAINT [PK_QDD_Liste_Indicatifs_telephone] PRIMARY KEY NONCLUSTERED 
		(
			[Id] ASC
		)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
		) ON [PRIMARY]
 
 
INSERT [QDD].[dbo].QDD_Liste_Indicatifs_telephone
	 VALUES
	  ( '33' , 2 , 'Hexagone' )
	, ( '033' , 3 , 'Hexagone' )
	, ( '0033' , 4 , 'Hexagone' )
	, ( '596' , 3 , 'Martinique' )
	, ( '590' , 3 , 'Guadeloupe' )
	, ( '262' , 3 , 'Reunion' )
	, ( '594' , 3 , 'Guyane' )
	, ( '508' , 3 , 'Saint_Pierre_et_Miquelon' )

J'ai testé de mettre en place un fonction scalaire mais il est impossible d'exécuter du code dynamique.

Et je n'arrive pas non plus à le faire via un procédure stockée :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
 
USE QDD ;
GO
 
/*Suppression de la SP existante */
DROP PROCEDURE dbo.[Indicatifs_Telephone] ;  
GO
 
CREATE PROCEDURE [Indicatifs_Telephone] 
	@Valeur nvarchar(50)
	AS 		
		DECLARE @SQL_INDICATIF NVARCHAR(4000) = N''
		SELECT @SQL_INDICATIF = @SQL_INDICATIF + N' 
			SUBSTRING (['+@Valeur+'], 1 , '+[Taille]+') = ('''+[Valeur]+''' ) 
			OR ' 
		FROM [dbo].[QDD_Liste_Indicatifs_telephone] ;
 
		SET @SQL_INDICATIF = LEFT(@SQL_INDICATIF, LEN(@SQL_INDICATIF) - 3);
		--PRINT @SQL_INDICATIF ;
 
		DECLARE @Resultat NVARCHAR(2) ;
 
		DECLARE @SQL_INDICATIF_2 NVARCHAR(4000) = N'
			IF '+@SQL_INDICATIF+' 
				BEGIN
						SET @Resultat = ''1'' ;
				ELSE 
						SET @Resultat = ''0'' ;
			END ' ;
 
		PRINT @SQL_INDICATIF_2 ;
		--EXEC @SQL_INDICATIF_2 ;
 
		PRINT @Resultat ;
 
SET QUOTED_IDENTIFIER OFF 
SET ANSI_NULLS ON 
 
GO
 
EXEC [QDD].[dbo].[Indicatifs_Telephone] @Valeur = '0655443322' ;
GO

Si vous avez une idée ou une méthode pour faire ce genre de chose, merci beaucoup par avance :-)

Il faut que cela ne soit pas trop gourmant car je vais faire appel à cette fonctionnalité sur des grosses tables de données clients.

Mille merci pour vos idée :-)

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

Il y a aucun intérêt à utiliser du sql dynamique dans votre cas.
Et utiliser du NVARCHAR dans votre table pour y stocker des nombres, sérieusement...
Même le choix du BIGINT comme Id à de quoi faire hurler.

[QuelJean]

Il y a aucun intérêt à utiliser du sql dynamique dans votre cas.
Et utiliser du NVARCHAR dans votre table pour y stocker des nombres, sérieusement...
Même le choix du BIGINT comme Id à de quoi faire hurler.

.... Je prends bonne note de tes retours… qui pourrait être plus sympathique sans nuire au message.

Mais à part te payer ma tête sur mon usage pas optimal des formats alors que je cherche encore un solution, tu n'apporte aucune aide, aucune solution , aucun conseil exploitables ...


Je t'avoues que c'est un peu décevant et pas vraiment bien veillant de ta part.

Bonne journée.

[binarygirl]

Mais en fait quel est le but ? Nettoyer des données j'espère ? A terme il faudrait normaliser le format d'entrée, pour que les futurs enregistrements soient conformes à un pattern strict. Par exemple, il y a beaucoup de sites qui demandent un numéro dans ce format: +33.612345678, ou qui demandent l'input des différents champs séparément.
Si c'est juste extraire les données sans les corriger, alors c'est un dév sans valeur ajoutée, qui ne fait que rajouter de la complexité et de la dette technique.

Car si on accepte 33, 033, 0033 pour la même zone on n'en sort plus.
Je ne comprends même pas l'intérêt de stocker la taille de l'indicatif... c'est une information déjà disponible via la fonction length... je ne comprends pas non plus le nvarchar(4000), les artifices (underscore dans le nom de pays)...
Si je vois ça chez un client, je gueule

A mon avis, il faudra éventuellement faire appel à des regex. On peut se baser sur le début de la chaîne et puis sa longueur mais il faut identifier les différentes possibilités existantes dans cette table.
Cela peut éventuellement passer par un select case pour aborder les différents cas, par exemple, si la chaîne commence par 0033, alors on attend 8 ou 9 chiffres derrière et en fonction de ça on sait si un préfixe est présent ou non. Bref, on peut s'en sortir avec une série de IF/ELSE, ce qui n'est pas élégant mais plus simple.

Mais encore une fois, ça devrait être dans l'objectif de corriger et normaliser les données, pas d'entériner et pérenniser le désordre.
Ce genre de code ne devrait même pas exister, si ce n'est pour une opération one-shot.

[SQLpro]

... je ne comprends pas non plus le nvarchar(4000)....

Pour information cela a généré des temps d'exécution monstre dans certaines requêtes que j'ai audité il y a des années. En effet on croit trop souvent que surdimensionner les colonnes d'une table n'a pas d'impact, même si les données sont toujours très petites... Or cela peut s'avérer catastrophique ! Je l'avais démontré chez un gros client (top 10 du CAC 40) ou une requête censé prendre 120 Mo en mémoire prenait plusieurs dizaines de Go pour s'exécuter !!! En effet, pour des raisons d'efficacité algorithmique, SQL Server va aligner les VARCHAR et NVARCHAR afin de ne pas avoir d'exécution en drapeau... Problème si tu as mis des n° de téléphone censés ne pas dépasser 20 caractères et que tu as mis du NVARCHAR(4000) alors s'il y a 1 millions de n° de tel, cela va demander 8 milliards d'octets à traiter... soit 7,5 Go !!!!!

A +

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

Mais à part te payer ma tête sur mon usage pas optimal des formats alors que je cherche encore un solution, tu n'apporte aucune aide, aucune solution , aucun conseil exploitables ...
Je t'avoues que c'est un peu décevant et pas vraiment bien veillant de ta part.

Désolé mais j'ai essayé de comprendre ton code et ça m'a frustré à toutes les lignes, j'ai donc laissé faire en restant poli.
Sinon j'aurais exprimé mon ressenti en disant que ça prendrait une formation SQL sérieuse.

Aucun conseil exploitables ? Il y en a un : choisir le bon type pour les bonnes données.
Un deuxième, ça se fait sans faire du sql dynamique.

Bonne continuation.