Structuur subscriber tabel, huisnr+toevoeging

#1

Ik vraag mij af waarom huisnummer en toevoeging tegenwoordig samengevoegd zijn.

Dit lijkt mij voor bepaalde zoekqueries niet bepaald handig.

zoek je bijvoorbeeld op postcode + huisnr dan is de kans groot dat je niets vind omdat er een toevoeging aan geplakt zit.

voorbeeld, 1234AA huisnr 1 kan niet worden gevonden omdat het er in staat als 1234AA met huisnr “1 A”.

zoeken op 1% heeft dan ook geen zin omdat je dan ook 10-19, 100-199 etc krijgt…

Is er een mogelijkheid om dit voortaan weer gesplitst te exporteren?

#2

Het wordt zo op CD gezet.

Numerieke huisnummers komen als BCD
http://www.foondump.nl/forum/viewtopic.php?p=876#876
-codes uit het databestand maar zodra er nog iets achter het huisnummer staat wordt het een string van het formaat “huisnummer/toevoeging”.

Als je zelf een csv-export uit het menu van de CD-foongids doet zie je het al:

    [b][size=9]"Naam";"Voorletters";"Straat";"Huisnummer";"Postcode";"Plaats";"Telefoon";"Fax";"E-mail";"Internet" "Aafjes";"R H";"Penseelstraat";"1/HUIS";"1073KX";"Amsterdam";"020-6931838";"";"";""[/size][/b]
Huisnummers en toevoegingen zelf scheiden is te doen maar je zal er even voor moeten gaan zitten omdat men niet consequent de schuine streep (ook wel slash, solidus, oblique, virgule, stroke, slant, forward slash, diagonal, over, slak, virgule of slat) als scheidingsteken gebruikt maar ook streepjes of spaties.

Volgens


de Posterijen (TNTPost) krijgt men voor automatische verwerking het beste resultaat met een spatie voor de toevoeging als die met een letter begint en verder hoofdletter(s), in plaats van een spatie een liggend streepje als het eerste teken van de huisnummertoevoeging een cijfer is.

#3

tja, dit is niet de mooiste oplossing maar ik split het nu inderdaad maar gewoon via een scriptje:

[code]<?

$db = mysql_connect(‘localhost’, ‘foondump’, ‘foondump’) or die('Could not connect: ’ . mysql_error($db));
if (!mysql_select_db(‘foondump2005’, $db)) echo "Could not connect to foondump: " . mysql_error($db);

echo "Add extension field to table… this will take some time… ";
mysql_query(“ALTER TABLE white_subscriber ADD extension VARCHAR( 15 ) NOT NULL AFTER housenumber;”);
echo “done\n”;
echo "examine all housenumbers and split in housenumber and extension… ";
$query = mysql_query(“select id,housenumber from white_subscriber”);
$c=0;
while ($array = mysql_fetch_array($query)) {
$h = “”;
$t = “”;

$id =  $array[id];
$hnr = $array[housenumber];
$len = strlen($hnr);
$gotoT = false;
for ($i=0;$i<=$len;$i++) {
	$p = $hnr{$i};
	if ($gotoT == false) {
		if (is_numeric($p)) {
			$h .= $p;
		} else {
			$gotoT = true;
			$t .= $p;
		}
	} else $t .= $p;
	
}

mysql_query("UPDATE `white_subscriber` set `housenumber`='$h', `extension`='$t' where `id`='$id'");
if ($c % 100 == 0) echo ".";
$c++;

}

echo “done: $c\n”;

echo “Altering table on housenumber and postalcode… this will take more time :)\n”;

mysql_query(“ALTER TABLE white_subscriber CHANGE housenumber housenumber MEDIUMINT(5) UNSIGNED NOT NULL;”);
mysql_query(“ALTER TABLE white_subscriber CHANGE postalcode postalcode CHAR(7) NOT NULL;”);

echo “Finished!!!\n\n”;

?>
[/code]

#4

Hoi Tim,

De keuze tussen aantal scheidingstekens (x miljoen) en de variatie in het extra veld ligt hier aan ten grondslag.

Zou best kunnen dat dit een probleem is.

Ik denk dat je zelf even de C code moet veranderen en hercompileren. Zou m.i. binnen 20 minuten kunnen.

De vriendelijke groet Jan Marco

#5

De grondslag is dat Foondump de data precies zo dumpt als in de cdfoongids aanwezig is. Het is dus niet onze keuze maar van de cdfoongids.

(1 uitzondering, streetnameextension komt zo weinig voor dat we die aan streetname plakken).

Het is geen probleem. LIKE gebruiken om te selecteren en naar een INTEGER casten om te sorteren. Zie ook de queries in fs2005.php

Ik denk dat dat tegen de gedachte van Foondump ingaat, om de data te dumpen zoals die in de gids staat. Dus dat is niet zo handig. Je moet de wijziging dan elke versie van Foondump zelf opnieuw maken.

Wat handiger is, is je SQL queries aanpassen, en dan is er niks aan de hand. Of de nu gebruikte oplossing inzetten, dat is op zich ook een slimme oplossing.

#6

Hoi Tim,

Wat ik nog van LIKE kan herinneren is dat het geen gebruik maakt van aanwezige indexen op tabellen, je krijgt m.i. een “tabel scan”.

De vriendelijke groet Jan Marco

#7

Dat is niet helemaal waar. Als je LIKE gebruikt met een wildcard (% of ?) aan het begin, kan geen gebruik worden gemaakt van indexen. LIKE ‘%kema’ kan immers zowel ‘alkema’ als ‘zalkema’ matchen.
Maar als je % op het einde gebruikt, dan is dat probleem er niet. ‘34%’ matched alleen huisnummers die alfabetisch met 34 beginnen. Dus 34-a, 34/AB of 341. Maar niet 12 en ook niet 9.

#8

[quote=“rgj”]Dat is niet helemaal waar. Als je LIKE gebruikt met een wildcard (% of ?) aan het begin, kan geen gebruik worden gemaakt van indexen. LIKE ‘%kema’ kan immers zowel ‘alkema’ als ‘zalkema’ matchen.
Maar als je % op het einde gebruikt, dan is dat probleem er niet. ‘34%’ matched alleen huisnummers die alfabetisch met 34 beginnen. Dus 34-a, 34/AB of 341. Maar niet 12 en ook niet 9.[/quote]

Ben ik toch niet volledig met je eens.
Ook in fs2005.php gaat het fout.

voorbeeldje, woon je op postcode 1234AB met huisnr 10 toevoeging A.
zoek je op 1234AB huisnr 10, komt er geen resultaat.

Inderdaad zoeken op “10%” zou een oplossing kunnen zijn…
echter wat je zegt over casten als integer, dat kan inderdaad… helaas kun je dat resultaat niet opnemen in je where clause.
Dus eigenlijk heb je niet zoveel aan het als integer gecaste huisnr.

Daarnaast krijg je bij het zoeken op 10% ook huisnr 100-109 en nog hogere huisnrs.
vervelender indien je zoekt op huisnr 1-9 want dan krijg je echt veel hits.
opzich natuurlijk niet erg als je handmatig iets opzoekt, wel vervelend tijdens een automatisch zoekproces :slight_smile:

Dus nogsteeds blijf ik erbij dat het opsplitsen met bovenstaande script hiervoor de beste oplossing is.

#9

Ik heb even mijn geheugen opgefrist en ik had inderdaad ooit een handigere truuk dan LIKE gevonden. Naar een integer casten werkt namelijk prima in een WHERE in MySQL, als je het impliciet doet.

Kijk en geniet:

mysql> select * from white_subscriber where postalcode='1058ST' and (housenumber+0.00) = 38; +---------+-------+-----------+-------+-----------+-------------------+-------------+------------+-----------+------------+----------+ | id | title | firstname | infix | lastname | streetname | housenumber | postalcode | city | phone | category | +---------+-------+-----------+-------+-----------+-------------------+-------------+------------+-----------+------------+----------+ | 349987 | | J | | Berends | Vogelenzangstraat | 38 3 | 1058ST | Amsterdam | 0206152627 | | | 1777958 | | J T J | | Gunther | Vogelenzangstraat | 38/II | 1058ST | Amsterdam | 0207768914 | | | 3392962 | | P | | Minks | Vogelenzangstraat | 38/HS | 1058ST | Amsterdam | 0206225257 | | | 3510504 | | N | | Nassla | Vogelenzangstraat | 38/I | 1058ST | Amsterdam | 0207779975 | | | 4303182 | | C M | | Scheepers | Vogelenzangstraat | 38/HS | 1058ST | Amsterdam | 0206225257 | | +---------+-------+-----------+-------+-----------+-------------------+-------------+------------+-----------+------------+----------+

Knap, want in fs2005.php wordt dus helemaal geen LIKE gebruikt voor huisnummers… :roll:

#10

[quote=“rgj”]Ik heb even mijn geheugen opgefrist en ik had inderdaad ooit een handigere truuk dan LIKE gevonden. Naar een integer casten werkt namelijk prima in een WHERE in MySQL, als je het impliciet doet.

Knap, want in fs2005.php wordt dus helemaal geen LIKE gebruikt voor huisnummers… :roll:[/quote]

AH :wink: thanks, dan weet ik gelijk waar t fout ging bij mij…
had de query uit fs2005.php overgenomen,
waarin het casten dus in de select gebeurd en niet in de where :slight_smile:
select (housenumber+0.00) as housenr where housnr = 1 werkt dus niet… :slight_smile:

echter ben ik nog wel van mening dat de index efficienter is op alleen integers in die kolom :slight_smile: maar daar valt wel mee te leven lijkt mij.

misschien trouwens een id om die query in t php script ook aan te passen naar de query die je net noemde ?

#11

Nee, want dan kan je niet meer op 38/A selecteren…