Beste ontwikkelaars,
wat is de reden dat de database structuur wisselt per versie?
is het niet handig om dit backwards compatible te houden met bestaande scripts? en daarvoor dezelfde structuur aan te houden?
Doel van de dump tools is om een zo getrouw mogelijke dump te maken, zonder aannames te hoeven doen over wat de data nou eigenlijk betekent.
Bijvoorbeeld wanneer Fullname = “Prof Dr Mr J Jansen” dan willen we niet hoeven ‘raden’ dat Prof Dr Mr de titels zijn en J een voorletter. Wat er dan gebeurt is dat in een latere release van de gids ineens een Ds (dominee) zit en dat de code dan denkt dat dat voorletters zijn.
Om dit te bereiken dumpen we de structuur van de gids 1-op-1, zonder bewerkingen. (En die structuur van de gids verandert dus elke paar jaar…)
In het verleden probeerde de makers van de dump tools wel alles in 1 structuur te ‘proppen’ en wat je zag gebeuren is dat bij elke release van de CDFoongids het dump programma crashte en dat men weer een nieuw programma moest maken. En vervolgens moest men de data analyseren om te kijken of het goed in de database kwam.
Daarnaast: als je 1 structuur kiest dan is dat nooit de structuur die de gebruiker graag wil. Die moet dan alsnog een conversie doen, en gaat bijvoorbeeld alle moeizaam uitgesplitste velden weer aan elkaar plakken.
Hoi T, RGJ,
Helemaal mee eens. Het wordt m.i. een chaos als je het wel zou gaan interpreteren.
T, Als je over jaren de informatie wil vergelijken zal je een database structuur “bovenop” foondump moeten plaatsen, waarbij je gaat analyseren hoe je Foondump bron gegevens er in krijgt. Kan dus elk release iets anders zijn. Daarnaast kan je natuurlijk de informatie gaan aanvullen/verbeteren door bijvoorbeeld een postcode check/DNS check uit te voeren.
Bovenstaande noem ik “datamanagement”. Ik hoop dat er mensen zich geroepen voelen om hiermee aan de gang te gaan. Ik denk dat je meer inzicht in de gegevens krijgt en uiteindelijk een betere telefoonboek.
De vriendelijke groet Jan Marco