[Mysql] Laadtijdverschil tussen delete,insert - update

[Verwijderd]

hallo,

ik ben bezig met een csv import tool voor mysql met PHP.

Het is een opdracht op mijn werk.

Ik heb de tool werkend.

Alleen mijn chef zegt dat het anders moet.

Ik delete eerst alle records uit de tabel.

Ik lees nu een txt bestand in en gebruik LOAD DATA INFILE
om het naar een tabel te schrijven.

dit werkt allemaal.

mij chef zegt dat dit niet de goede manier is.
Hij wilt de csv eerst naar een temp table schrijven.
dan de definitieve tabel vergelijken met de temp table.
zijn er records verwijdert uit de csv dan moeten die ook uit de
definitieve tabel verwijdert worden.

hij wil dit omdat hij zegt dat het laadtijd scheelt.
het gaat om ongeveer 100.000 records.

scheelt dit heel veel tijd?
of is mijn manier net zo traag/snel als die van hem?

[Verwijderd]

Ik persoonlijk ga voor jouw manier, veel sneller dan een csv inserten mbv LOAD DATA INFILE kan volgens mij idd niet. De manier van je baas veroorzaakt nogal veel overhead imo.
Het kan nog sneller door je indexen eerst te verwijderen, data te inserten en daarna de indexen weer op te bouwen

[Bosmonster]

Dus jij gooit alles weg en laad het in een tabel

je baas wil het eerst in een tijdelijke tabel laden (daar zit je al aan je eigen oplossing) en dan nog eens gaan vergelijken etc...

hmm.. lijkt me duidelijk

Als het gaat om het vervangen van data en je krijgt alleen een compleet bestand aangeleverd dan lijkt jouw optie me ook de enige oplossing. Scheelt je een hoop load en een berg programmeren (met de onvermijdelijke bugs ).

Wil je de baas zijn oplossing dan kunnen beter sowieso al alleen de wijzigingen opgestuurd worden..

[ Voor 44% gewijzigd door Bosmonster op 19-11-2004 12:24 ]

[Verwijderd]

Aan beide systemen zitten voor en nadelen. Groot voordeel van de methode van de baas(omdat die er nogal bekaaid vanaf komt in de andere posts), records die al in het systeem zitten en niet in de import tabel zitten worden niet verwijderd.
Je kan dus in dat geval met Delta records werken in plaats van elke keer de hele tabel te moeten vervangen. Dit kan vele malen sneller zijn dan een botte import. Een tweede voordeel is dat het record altijd blijft bestaan. Als er iemand tijdens jou import een van die (tijdelijk) verwijderde records wil benaderen, zit je met een probleem. De methode van de baas heeft hier geen last van. Ook heeft de methode van de baas als voordeel dat er niet elke keer 10.000 records verwijderd en weer opnieuw aangemaakt hoeven te worden. Niet alle databases vinden dat even prettig ivm de indexen.

Maar als je de hele tabel wilt vervangen is jou methode waarschijnlijk sneller. De import doe je toch al (in het geval van de baas naar de temp tabel) en het verwijderen zoeken en updaten zal meer tijd kosten dan botweg alles deleten.

Zo moeilijk is het echter niet wat je baas wilt

Creeer een temptabel t1 en gooi daar alle data in, vergeet vooral geen primary key op deze tabel te definieren. Die zul je nodig hebben
doe iets als
- DELETE FROM MAINTABLE WHERE ID NOT IN select T1.ID
- UPDATE MAINTABLE SET MAINTABLE.VELD=T1.VELD WHERE ID=T1.ID
- INSERT INTO MAINTABLE () SELECT * FROM T1. WHERE T1.ID NOT IN SELECT MAINTABLE.ID FROM MAINTABLE
of ipv de insert met NOT IN (traag)
- DELETE FROM T1 WHERE MAINTABLE.ID=T1.ID
- INSERT INTO MAINTABLE () SELECT * FROM T1

[Soultaker]

Het lijkt me dat het voorstel van de baas vooral zinnig is om te voorkomen dat de tabel tijdens het verwerken leeg is. Dat kan hele vervelende gevolgen hebben voor een live systeem. In dat geval zou je dus kunnen overwegen om eerst de nieuwe tabel op te bouwen en die daarna op een veilige manier om te wisselen met de echte tabel.