Tutorials

best practices bij het schrijven van importeer scripts

In deze tutorial ga ik langs de meest voorkomende problemen bij een importscript en geef ik je richtlijnen waarbij je een goed importeerscript kunt maken.

Pagina 1

Inleiding

In grotere bedrijven komt het wel eens voor dat je een importscript moet schrijven om zo gegevens uit bepaalde bronnen in je eigen CRM pakket te kunnen gebruiken. Hoe groter het aantal gegevens des te trager kan zo'n importeerscript worden. Gebruikers worden ongeduldig, denken dat een script niet meer reageert en kunnen geen andere dingen doen met het CRM in een ander tabblad.

In deze tutorial ga ik je een aantal tips geven die je op weg helpen om een gebruiksvriendelijk en optimaal importeer script op te bouwen.
Pagina 2

Upload of externe database uitlezen

Externe database
Bij het gebruik van een externe database gebruik je het liefst een query die alleen de data ophaalt die je daadwerkelijk nodig hebt.
Laat de gebruiker bijvoorbeeld een datum-range opgeven en Selecteer alleen de kolommen die je nodig hebt.
De Structured Query Language is een erg krachtige taal en de database engine is doorgaans sneller dan dat de verwerking met PHP gedaan kan worden. Probeer dus zoveel mogelijk af te handelen aan de kant van de database.
Gebruik zoveel mogelijk Joins indien je van de zelfde server meerdere tabellen moet aanspreken.

Upload
Bij het uploaden is het aan te raden om met CSV of XML formaat te werken. Dit is plaintext en makkelijk uit te lezen met de voor handen zijnde functies in PHP. (voor XML moet je in de gaten houden dat je misschien een extensie aan moet zetten in php.ini).
Wanneer je grote bestanden upload kan het handig zijn gebruik te maken van scripts als uploadify welke een progressbar tonen voor het uploaden. Zodoende kun je ook meerdere bestanden te gelijk uploaden.
Sla het bestand bij voorkeur op in de temporary directory of in een directory die niet benaderbaar is van buitenaf.

Bij beide methoden is het erg belangrijk: bereid je data voor zoals je ze in je eigen database wilt komen te staan. Heeft een status kolom bijvoorbeeld cijfers, maar gebruik jij letters? zet deze cijfers dan eerst om naar de juiste letter. Dit kun je bij databases doorgaans al in de query uitvoeren.

Pagina 3

Het importeren

Wanneer je alle gegevens hebt ingelezen en voorbereid kan het importeren beginnen. Bij het importeren naar een database kun je bijvoorbeeld insert queries uitvoeren waarbij je kan aangeven dat indien de record bestaat dit record geupdate mag worden. Zodoende voorkom je dubbele records zonder dat de query faalt op basis van bijvoorbeeld primary of unique keys.
Pagina 4

De gebruikers interface

Terwijl het script draait hebben we doorgaans de oude pagina voor ons of een witte lege pagina. Dit is niet erg netjes.

Door het script via AJAX aan te roepen kun je bijvoorbeeld gebruik maken van een progressbar. Nu we weten dat sessions de boel opslot zetten en dat we mogelijkheid hebben om dit bestand te sluiten kun je in het draaiende script gegevens van het aantal records en het aantal verwerkte records in de sessie opslaan en zodoende met een ander ajax scriptje deze gegevens ophalen en een progressbar te genereren.

Session_start en session_write_close kun je zovaak gebruiken als je maar wilt. In feite open je tijdelijk een bestand en sluit je hem weer als je klaar bent. Je kunt natuurlijk ook de informatie in een database tabel zetten, maar dat zal het importeerscript ernstig vertragen.

Je kunt voor een simpele progressbar de progressbar van jQueryUI gebruiken.
Pagina 5

Het sessieprobleem

Dergelijke importeerscripts moet je uiteraard beveiligen en dit wordt doorgaans via de sessie geregeld. Echter is het gebruik van Sessie ook een enorm bottleneck wanneer je tijdens de import andere taken wil uitvoeren en met name bij grotere scripts kan dat nog wel eens vervelend zijn. Ik zal hieronder even kort uitleggen wat het probleem is.

PHP schrijft sessie gegevens standaard weg naar een bestand. met session_start() wordt dat bestand ingelezen en zo nodig nieuw aangemaakt. Om corruptie te voorkomen wordt het bestand gelocked zodat andere scripts het bestand niet in kunnen zien of bewerken. Dit betekend concreet dat wanneer een gebruiker je webapplicatie opent via een tweede tabblad, de pagina niet geladen zal worden tot dat je importeerscript klaar is met het verwerken van de data.

Gelukkig hebben we doorgaans de sessie niet meer nodig op het moment dat het script begint met uitlezen en verwerken van de data en kunnen we dus doormiddel van session_write_close() het bestand vrijgeven. Zodoende kunnen andere scripts gedraaid worden terwijl je importeerscript bezig is.

Een andere oplossing, welke misschien wat ingewikkelder is, is een andere session save handler te gebruiken zoals een database. Hoe je dit moet doen ga ik verder niet op in.

Reacties

0
Nog geen reacties.