🚀 go-pugleaf

HomeAutomation Freak (HomeAutomation.invalid@pandora.be) wrote:
> ik heb een MS SQL DB, met daarin in velden, telefoonnummers (als
> varchar)
> deze telefoonnummers zitten er "geformateerd" in,
> dwz. 031234567 zit erin als +32(0)3-1234567,
> maar kan er evengoed als 03/123.45.67. of andere varianten inzitten.
> 
> de bedoeling is nu om een select te doen, die "alleen nummers"
> teruggeeft.
> 
> ik heb al voor bepaalde tekens een replace ingebouwd in m'n select,
> maar dit wordt nogal onoverzichtelijk om alle niet-numerische tekens
> eruit te filteren op die manier.
> 
> Is er een alternatief ???

Een stored procedure misschien?

SELECT AlleenNummer(TelNr), Name FROM Addresses;

CREATE FUNCTION AlleenNummer AS [... enz, ik ken MS SQL niet]

-- 
Erik Hensema (erik@hensema.net)                             ICQ# 8280101
Reality is for those who can't face Science Fiction.

On Sun, 21 Sep 2003 12:18:28 GMT, HomeAutomation Freak wrote:
> dwz. 031234567 zit erin als +32(0)3-1234567,
> maar kan er evengoed als 03/123.45.67. of andere varianten inzitten.
> de bedoeling is nu om een select te doen, die "alleen nummers"
> teruggeeft.

In plaats van veel tijd investeren in een mooie, slimme of snelle
oplossing (altijd leuk), zou je misschien ook een extra kolom kunnen
toevoegen 'telnr_kaal' en 1x de conversie uitvoeren. Werkt allicht
niet als er de hele tijd veranderingen in 'telnr' gemaakt worden.

>
>In plaats van veel tijd investeren in een mooie, slimme of snelle
>oplossing (altijd leuk), zou je misschien ook een extra kolom kunnen
>toevoegen 'telnr_kaal' en 1x de conversie uitvoeren. Werkt allicht
>niet als er de hele tijd veranderingen in 'telnr' gemaakt worden.

Hmm, het is een tabel met een paar honderdduizend records,
zo wordt m'n database ineens weer wat MB's meer h� ;-)

soit, heb het opgelost met nested replace functions:

dus:
SELECT
	Name,
	Tel
FROM
	Addresses
WHERE

replace(replace(replace(replace(replace(replace(Tel,'-',''),'/',''),'
',''),'.'),'(',''),')','')

is nog redelijk doenbaar, en is ook correct, aangezien in het
programma zelf, bij de invoer van nummers, alleen maar numerische
waardes, en verder een spatie en volgende karakters geldig zijn -./()


greetz,
Kris

HomeAutomation Freak wrote:

>>In plaats van veel tijd investeren in een mooie, slimme of snelle
>>oplossing (altijd leuk), zou je misschien ook een extra kolom kunnen
>>toevoegen 'telnr_kaal' en 1x de conversie uitvoeren. Werkt allicht
>>niet als er de hele tijd veranderingen in 'telnr' gemaakt worden.
> 
> Hmm, het is een tabel met een paar honderdduizend records,
> zo wordt m'n database ineens weer wat MB's meer h� ;-)

En wat dacht je van: ��nmaal de conversie doen, en de frontend aanpassen dat
nummers er altijd kaal worden ingestoken?

-- 
Mvg, JeroenV
<URL:http://www.briachons.org/>

>
>En wat dacht je van: ��nmaal de conversie doen, en de frontend aanpassen dat
>nummers er altijd kaal worden ingestoken?

dat zou betekenen dat alle nummers volgens ��nzelfde "formaat" zouden
moeten getoont worden.
een gebruiker moet de kans krijgen om op eender welke plaats in de
telefoonnummer, die haakjes, punten, schuine strepen enz ... te
gebruiken.
(nationale nummers, internationale nummers, interne nummers, GSM
nummers)
immers, zone 02 & zone 016, daar zou je bij het terug inlezen het
verschil niet tussen zien h�.

HomeAutomation Freak wrote:
>>In plaats van veel tijd investeren in een mooie, slimme of snelle
>>oplossing (altijd leuk), zou je misschien ook een extra kolom kunnen
>>toevoegen 'telnr_kaal' en 1x de conversie uitvoeren. Werkt allicht
>>niet als er de hele tijd veranderingen in 'telnr' gemaakt worden.
> 
> 
> Hmm, het is een tabel met een paar honderdduizend records,
> zo wordt m'n database ineens weer wat MB's meer h� ;-)

Een paar honderd KB * 10 cijfers is inderdaad slechts een paar MB, dus 
daar zou ik het niet voor laten.

Ik zou zeker niet voor iedere query een paar honderduizend * 6 
string-replacements uitvoeren, want dat zal waarschijnlijk behoorlijk 
wat performance gaan kosten. Ik weet niet of er veel mensen op die 
database gaan werken...

vr. gr,

Harro.

HomeAutomation Freak wrote:

> Hmm, het is een tabel met een paar honderdduizend records,
> zo wordt m'n database ineens weer wat MB's meer h� ;-)

Ja, maar de betreffende kolom is opeens wel index friendly! Ff een non 
unique index en het gaat als de brandweer!


M.v.g.,
Ramon


--
Ramon Smits aka. Exyll
http://www.exyll.net/ (ipv6 enabled)

"HomeAutomation Freak" <HomeAutomation.invalid@pandora.be> schreef in
bericht
> deze telefoonnummers zitten er "geformateerd" in,
> dwz. 031234567 zit erin als +32(0)3-1234567,
> maar kan er evengoed als 03/123.45.67. of andere varianten inzitten.
>
> de bedoeling is nu om een select te doen, die "alleen nummers"
> teruggeeft.

Ik weet niet of je versie 2000 gebruikt, maar dan kun je een UDF maken die
dit voor je doet zodat je niet in iedere query die hele replace code hoeft
te gebruiken. Volgens mij is jou veld een vrij tekstveld en kan ieder
karakter (ook per ongeluk ingetypt) kunnen voorkomen en dan werkt je code
niet meer, in een UDF kun je alle digits filteren enm retourneren.

Eigenlijk zou je applicatie al een standaard formaat moeten wegschrijven of
zou je met een trigger kunnen controleren of er ongeldige tekens zijn
ingevoerd. En zoals andere postings: schrijf een tweede veld weg met alleen
het telefoonnummer, dan kun je er ook op zoeken. En wees maar niet bang dat
de db te groot wordt, ik heb hier een db > 60 Gb (tabellen met >100 miljoen
records) en een selectie heb ik nog steeds in 1/10 seconde.

Rene