[mysqll/php] 29.000 rows updaten

[Bananenspin]

Iemand heeft ooit besloten om datum's op te slaan in dit formaat: 2008-12-06 14:46:00 en ik heb toch liever een unix timestamp dus die moeten worden omgezet. Een strtotime() erop werkt alleen hoe ga ik voor elke record een strtotime erop gooien en dan weer een update query draaien? Heb kleinschalig (10 results) geprobeerd om ze over te zetten naar een array in unix timestamp tijd en id erbij, om vervolgens 10 keer een update date where id = $id te draaien maar dat gaat ook niet helemaal goed.. en dan nog maar te zwijgen over het feit of de server het leuk gaat vinden als ik dat met 10 (of meer queries ga doen). Can somebody help me out?

ps: een mysql query om dit op te lossen mag ook natuurlijk!

[Voor 4% gewijzigd door Bananenspin op 20-10-2012 20:47]

[Merethil]

Is het niet gewoon elke row ophalen, date pakken, strtotime, update over row en volgende row pakken?

Je kan gewoon alles ophalen, 1 voor 1 doorlopen en weer terugplaatsen. Lijkt me het makkelijkst.

[Anoniem: 479080]

Wat Merethil zegt. Uiteraard zal je pagina enige tijd laden met 29.000 rows maar dat is natuurlijk wel aanvankelijk van de snelheid van je server.

[HeSitated]

Mijn werkwijze zou zijn kolom toevoegen, in een keer de nieuwe kolom updaten en dan de oude kolom verwijderen of updaten vanuit de nieuwe kolom.

[Voyage]

Ik zou niet regel voor regel een update query uitvoeren. Ik zou zelf een aantal rijen ophalen de datums in je applicatie wijzigen en vervolgens via een batch updaten.

Regel voor regel updaten is erg inefficiënt.

[Cartman!]

Het is een eenmalig iets, daar zou ik niet al te moeilijk over doen. Desnoods bouw je er ff een sleep in om elke X aantal records.

[Nic]

waarom laat je mysql niet zelf rekenen?
Ik heb geen ervaring met mysql maar wel veel met MSSQL, en die kan gewoon alles zelf in een keer. Dat zou met mysql toch ook moeten kunnen? Ik zie een functie 'TO_SECONDS' die een datetime naar een unix timestamp kan omzetten:
http://dev.mysql.com/doc/....html#function_to-seconds

In dat geval zou je gewoon een (tijdelijk) extra veld kunnen aanmaken, en dan

code:

update tablename set tijdveld_new=TO_SECONDS(tijdveld_oud)

en klaar ben je voor 29000 records. Met mssql zou die query voor zoveel(/weinig) records niet langer dan een paar seconden duren.

[Dadona]

Kleinschalig testen. Maar je kunt gewoon een update en select combineren.

UPDATE suboptimale_tabel SET datum = (SELECT conversie...(datum) FROM suboptimale_tabel)
...zeg maar waar dsltv het ook over heeft.

[Voor 31% gewijzigd door Dadona op 20-10-2012 21:16]

[NMe]

TO_SECONDS rekent vanaf 1 januari in het jaar 0, je moet UNIX_TIMESTAMP hebben. Verder is het inderdaad één simpele update-query als je gewoon die functie gebruikt.

Ik zie trouwens het nut van het omzetten niet. Ik gebruik liever een date die ik vervolgens in PHP wel door strtotime haal. Dan hou ik mijn database ook leesbaar in phpMyAdmin.

[Voor 35% gewijzigd door NMe op 20-10-2012 21:18]

[Gomez12]

Wat is nu precies je probleem?

Herhaal je testje 2900 x en je bent er toch?

In principe zou ik zeggen : nieuwe kolom aanmaken en dan in 1x alle rijen erdoorheen gooien met 1 update statement, maar ik heb zomaar het vermoeden dat mijn servers niet zo zwaar onderbemeten zijn als de jouwe.

Alhoewel ik zelfs op de meest onderbemeten server dit gewoon zou uitvoeren in 1x en verbaasd zou zijn als het langer als 1 seconde zou duren (29.000 rows is niets)

Maar ok, stel dat het 3 uur zou duren (10.000 rows per uur ) dan zou ik gewoon een cron-job inplannen die dit om 02:00 vannacht doet zodat het morgen goed staat.

Conclusie : Zie het in een sql-statement te proppen (kan makkelijk) die het in 1x uitvoert en 1 sec later staat het goed.

P.s. ik vind het schitterend hoe bezorgd iedereen hier is. Alles onder de 100.000 records valt bij mij al onder kleinschalig testen Bij alles onder de 10.000 rows vraag ik me al af of de verbindingsopbouw niet al >50% van de tijd gaat kosten

[NMe]

Ik zou érg verbaasd zijn als dit niet in 2 seconden klaar is...

[Dadona]

Wie weet moet dit op een Raspberry Pi gebeuren zonder dat de gebruikers er iets van merken? Maar inderdaad, een UPDATE-SELECT van deze vorm is op normale hardware zo gebeurd.

[NMe]

Hoezo UPDATE-SELECT?

MySQL:

UPDATE tabel SET nieuwe_kolom = UNIX_TIMESTAMP(oude_kolom)

Veel makkelijker wordt het niet. Daarna even de oude kolom weghalen en eventueel de nieuwe hernoemen en klaar is Kees. Dat gaat zelfs op die hypothetische Raspberry Pi binnen een paar seconden, zelfs nog terwijl hij aan het streamen is o.i.d.

[Cartman!]

Persoonlijk heb ik ook liever datetime-velden in m'n tabellen, direct leesbaar en mbv. DateTime kun je t formatten hoe je wilt

[Bananenspin]

Dadona schreef op zaterdag 20 oktober 2012 @ 21:14:
Kleinschalig testen. Maar je kunt gewoon een update en select combineren.

UPDATE suboptimale_tabel SET datum = (SELECT conversie...(datum) FROM suboptimale_tabel)
...zeg maar waar dsltv het ook over heeft.

Ben vrij slecht in subqueries, had wel verwacht dat het kon maar de uitwerking kon ik niet zo snel bedenken, dat moet nu wel lukken zo!

NMe schreef op zaterdag 20 oktober 2012 @ 21:17:
Ik zie trouwens het nut van het omzetten niet. Ik gebruik liever een date die ik vervolgens in PHP wel door strtotime haal. Dan hou ik mijn database ook leesbaar in phpMyAdmin.

Hmm daar heb je wel een punt, ging me ook om consistent zijn, soms is er wel een UNIX timestamp gebruikt maar dan kan ik de hulp die ik hier gekregen heb natuurlijk ook gebruiken om die om te zetten naar een date.

Dadona schreef op zaterdag 20 oktober 2012 @ 21:21:
Wie weet moet dit op een Raspberry Pi gebeuren zonder dat de gebruikers er iets van merken? Maar inderdaad, een UPDATE-SELECT van deze vorm is op normale hardware zo gebeurd.

Die is helaas nog niet binnen maar nee ik had geen flauw benul hoelang de query zou gaan duren.

[NMe]

Een query die niet miljoenen records gaat muteren en waar mogelijk netjes gebruik maakt van indices is in zijn geheel niet spannend wat tijd betreft. 29k records is niks.

[Dadona]

NMe schreef op zaterdag 20 oktober 2012 @ 21:26:
Hoezo UPDATE-SELECT?

MySQL:

UPDATE tabel SET nieuwe_kolom = UNIX_TIMESTAMP(oude_kolom)

Veel makkelijker wordt het niet. Daarna even de oude kolom weghalen en eventueel de nieuwe hernoemen en klaar is Kees. Dat gaat zelfs op die hypothetische Raspberry Pi binnen een paar seconden, zelfs nog terwijl hij aan het streamen is o.i.d.

Het kan aan mij liggen, maar ik dacht dat het toevoegen en verwijderen van kolommen een iets mindere actie is. Overhead/performance/... Maar ik begeef mij volgens mij nu op glad ijs . Er was een reden dat ik voor mijzelf maar heb onthouden om het, als het goed zonder kan, zonder rommelen met kolommen te doen.

[Voor 7% gewijzigd door Dadona op 20-10-2012 21:35]

[Gomez12]

Dadona schreef op zaterdag 20 oktober 2012 @ 21:34:
[...]
Het kan aan mij liggen, maar ik dacht dat het toevoegen en verwijderen van kolommen een iets mindere actie is. Overhead/performance/... Maar ik begeef mij volgens mij nu op glad ijs .

29.000 rows, daar is performance geen issue. Dat is milliseconden werk.

Dan heb je (theoretisch wellicht) 2000% performance loss en dan zit je op 5 seconden oid.

Het intikken van de 1e zin van de TS koste waarschijnlijk al meer tijd dan het simpelweg draaien van de query.

Performance is leuk voor veel voorkomende werkzaamheden, maar voor vele eenmalige/admin werkzaamheden is het uitdenken van een performance oplossing langer dan het simpelweg draaien.

Zoals ik al zei, plan een admin actie om 02:00 's nachts en dat ding kan 3 uur draaien en is alsnog tig keer sneller dan dat jij er 8 uur over gaat zitten piekeren wat de beste performance geeft.

Eenmalige acties zijn zo af en toe gewoon : f*ck performance en draaien maar op een rustig tijdstip

[Dadona]

Snap ik...snap ik. De vraag lijkt mij nu wel beantwoord, maar dan is het nu toch tijd voor het echt educatieve deel. Small scale test weten we, maar nu...met wat gaat de zaak het snelst stuk bij een triljoen entries.
Ik ben echt benieuwd, is het toevoegen en verwijderen van kolommen nu echt iets waar je in principe niet aan moet willen? In ieder geval als het echt om indrukwekkende aantallen entries gaat. Ik ga het zo zelf maar eens uitzoeken.

[Gomez12]

Dadona schreef op zaterdag 20 oktober 2012 @ 21:44:
met wat gaat de zaak het snelst stuk bij een triljoen entries.
Ik ben echt benieuwd, is het toevoegen en verwijderen van kolommen nu echt iets waar je in principe niet aan moet willen? In ieder geval als het echt om indrukwekkende aantallen entries gaat. Ik ga het zo zelf maar eens uitzoeken.

Definieer stuk

Maar in principe is het toevoegen en verwijderen van kolommen af te raden vanwege index-updates die ook over die kolommen kunnen lopen / fragmentatie van je db etc.
Maar dan heb je het veelal wel over een tmp-kolom die enkel toegevoegd voor de tijd dat het proces loopt en dat je daarna dezelfde kolommen behoud.

Wil je simpelweg een column van type veranderen dan heb je toch al alle "schade" aan je indexen etc en dan voldoet het over het algemeen beter om je normale indexen uit te schakelen, temporary indexen aan te gooien die je helpen bij je admin-actie en aan het einde de temporary indexen weg te gooien en de normale indexen in 1x weer aan te zetten.

Bij triljoenen rows (of >10 miljoen) wil je simpelweg niet 10 miljoen index-updates hebben dat is kostbaar, dus dat moet je voorkomen.
En als je grote rows hebt dan kan het bijv weer handiger zijn de te bewerken kolom in een aparte tmp-tabel te zetten, daarop je acties uit te voeren en daarna het resultaat weer te updaten in de originele tabel.

Maar bij <1 miljoen rows zou ik nog niet eens nadenken over dit soort maatregelen omdat het uitwerken ook weer tijd kost

[Dadona]

Ah, ik ben dus niet helemaal gek. Bedankt.

[Bananenspin]

Nu dit topic er toch is zal ik er nog maar een vraag instellen, is er ook een mogelijkheid op bepaalde woorden (bv html tags als <p>) eruit te filteren op een zelfde soort manier? Of zal PHP daar wel benodigd voor zijn.

[NMe]

Dat je al een topic hebt wil niet zeggen dat je dan maar elk simpel vraagje hier kan dumpen zonde zelf even wat moeite te doen. Heb je zelf al eens naar de verschillende stringfuncties gekeken? Wat dacht je van de verschillende replace-functies?

[Bananenspin]

Sorry, heb natuurlijk gekeken naar mysql string functie's alleen vroeg ik me dus af hoe snel dat ook in dit geval gaat, of een query daar ook veel sneller in is dan een PHP functie.

[Zoijar]

Grappig altijd om te lezen dat mensen moeilijk doen over iets als 29k records -- dat ze denken dat dat veel tijd kost of dat je daar diep over na moet denken -- terwijl eigenlijk elke oplossing het instantaan doet. Aan de andere kant vindt men het normaal dat je een miljoen pixels op je scherm 60 keer per seconde berekent

[Bananenspin]

9495 rij(en) bijgewerkt. ( Query duurde 12.3541 sec )
UPDATE gc_items SET content = REPLACE( content, '<p style="text-align: justify;">', '<p>' )

12 seconden is nog best aardig wat! Vroeg het vooral omdat je in codes nog sleep kan inbouwen eventueel maar goed ik voel me nu wel wat zekerder om zulke query's te draaien.

[Dadona]

Zoijar schreef op zondag 21 oktober 2012 @ 13:53:
Grappig altijd om te lezen dat mensen moeilijk doen over iets als 29k records -- dat ze denken dat dat veel tijd kost of dat je daar diep over na moet denken -- terwijl eigenlijk elke oplossing het instantaan doet. Aan de andere kant vindt men het normaal dat je een miljoen pixels op je scherm 60 keer per seconde berekent

Mwa, het tegenovergestelde kan ik ook wel zeggen. Grappig dat het ontwikkelaars totaal niet boeit dat iets wat meer geheugen of wat meer opslagruimte kost, toch zat. En opeens zit je met een 'kale' printer / bluetooth driver van 300MB.
Maar goed, inderdaad moet je altijd gewoon even afwegen of het echt relevant is. In dit geval voldoet inderdaad alles wel.

[Gomez12]

Bananenspin schreef op zondag 21 oktober 2012 @ 14:12:
12 seconden is nog best aardig wat! Vroeg het vooral omdat je in codes nog sleep kan inbouwen eventueel maar goed ik voel me nu wel wat zekerder om zulke query's te draaien.

Code heeft altijd het nadeel van connecties opbouwen en het "niet" kunnen uitvoeren van set-based structuren.

Stel dat het versturen van 1 query vanuit php naar mysql 1 ms duurt. Als je dan je 29k records per record gaat query'en (1 select en 1 update per record, worst case) dan zit je dus al minimaal aan 58000 ms. En dat is 58 seconden aan enkel overhead, terwijl je met 2 query's dan maar aan 2 ms aan overhead zit.

Wil je toch dingen als sleep etc erin bouwen dan alsnog niet alle data overhalen naar php maar bijv je max rowcount delen door 10 (of een andere simpele methode om een ongeveer evenwichtig aantal rows te bewerken) en dan daar de pk's van opvragen. Zodat je in je update query's kan meegeven where pk<x and pk>y (ik weet zo snel niet of mysql ook limits op update-query's accepteert)
Dan doe je het alsnog in een stuk of 30 query's ipv 58.000.

En stel dat je toch een heel erg ingewikkeld iets moet doen wat echt in code moet dan kan je alle rows ophalen en dan de update-query in code opbouwen en per 10.000 oid naar de mysql-server sturen (dat scheelt weer 9999 keer overhead)

En algemene tip : Zet bij een update query altijd een where-conditie als je niet alles wilt aanpassen, in het ergste geval haalt de query-optimizer de where weg en in het beste geval is je query tig keer sneller (plus dat je je query dan in 2 sec kan checken door er een select-query van te maken)

P.s. in je laatste query zou ik persoonlijk nog even een check doen om te zien of er niet nog iets is wat : like *<p * bevat, want je pakt nu echt enkel maar 1 specifiek randgeval.

Dadona schreef op zondag 21 oktober 2012 @ 14:53:
[...]
Mwa, het tegenovergestelde kan ik ook wel zeggen. Grappig dat het ontwikkelaars totaal niet boeit dat iets wat meer geheugen of wat meer opslagruimte kost, toch zat. En opeens zit je met een 'kale' printer / bluetooth driver van 300MB.
Maar goed, inderdaad moet je altijd gewoon even afwegen of het echt relevant is. In dit geval voldoet inderdaad alles wel.

Let er wel op dat het hier om eenmalige / admin acties gaat. Die dingen horen niet in een 'kale' printer/bluetooth driver te zitten.

[NMe]

Bananenspin schreef op zondag 21 oktober 2012 @ 14:12:
9495 rij(en) bijgewerkt. ( Query duurde 12.3541 sec )
UPDATE gc_items SET content = REPLACE( content, '<p style="text-align: justify;">', '<p>' )

12 seconden is nog best aardig wat! Vroeg het vooral omdat je in codes nog sleep kan inbouwen eventueel maar goed ik voel me nu wel wat zekerder om zulke query's te draaien.

Spreekt redelijk voor zich omdat er voor elk record naar dat veld gekeken moet worden om te zien of die tekst daarin voorkomt. De daadwerkelijke replace is daarna peanuts. Replaces binnen een veld kun je beter in PHP doen. Had ik in mijn vorige post kunnen zeggen maar wat ik met die post wilde bereiken is vooral dat je even zou zien wat het verschil is. Dat maakt het makkelijker voor je om vooraf te bedenken wat de beste oplossing is.

Dadona schreef op zondag 21 oktober 2012 @ 14:53:
[...]
Mwa, het tegenovergestelde kan ik ook wel zeggen. Grappig dat het ontwikkelaars totaal niet boeit dat iets wat meer geheugen of wat meer opslagruimte kost, toch zat. En opeens zit je met een 'kale' printer / bluetooth driver van 300MB.

Een ontwikkelaar die een paar uur devtijd kan besparen maar daarvoor wat extra geheugen of opslag nodig heeft is nog goedkoper dan die betere oplossing helemaal uitwerken. Vergeet niet dat loonkosten nog altijd veel hoger zijn dan vrijwel alle andere kosten die een bedrijf kan maken.

[Gomez12]

NMe schreef op zondag 21 oktober 2012 @ 15:14:
[...]

Spreekt redelijk voor zich omdat er voor elk record naar dat veld gekeken moet worden om te zien of die tekst daarin voorkomt. De daadwerkelijke replace is daarna peanuts. Replaces binnen een veld kun je beter in PHP doen.

I don't agree

Voordat je je replaces binnen php kunt doen moet je toch nog steeds de dbase opdracht geven om binnen dat veld te kijken of die tekst daarin voorkomt (middels een where), dus het zware werk moet alsnog gedaan worden...

Enige mogelijkheid dat ik je antwoord zou kunnen begrijpen is als je het specifiek op deze dataset van 29k rows bedoelt, dan zou je van alle records het pk en het veld naar php kunnen overhalen zonder filtering en dan php erover laten itereren maar dat gaat gruwelijk traag bij grotere hoeveelheden records.

Wat over het algemeen wel het beste werkt met dit soort dingen is een soort half-half oplossing. In je db zoek je een simpele manier om grofweg de juiste rows eruit te krijgen, dan krijg je bijv 12.000 rows terug waarvan er maar 9545 100% juist zijn. Over die recordset itereer en filter je met php zodat je exactere /flexibelere stringfuncties kan uitvoeren. Dan kan het wel weer, maar ik zou nooit itereren over de complete dataset met php.

[Patriot]

NMe schreef op zondag 21 oktober 2012 @ 15:14:
[...]

Een ontwikkelaar die een paar uur devtijd kan besparen maar daarvoor wat extra geheugen of opslag nodig heeft is nog goedkoper dan die betere oplossing helemaal uitwerken. Vergeet niet dat loonkosten nog altijd veel hoger zijn dan vrijwel alle andere kosten die een bedrijf kan maken.

Aan de andere kant valt er wat voor te zeggen dat je als producent die extra uurtjes even voor lief neemt, zodat je niet miljoenen klanten met extra geheugengebruik opzadelt.

[Gomez12]

Patriot schreef op zondag 21 oktober 2012 @ 18:03:
[...]
Aan de andere kant valt er wat voor te zeggen dat je als producent die extra uurtjes even voor lief neemt, zodat je niet miljoenen klanten met extra geheugengebruik opzadelt.

Hoeveel extra uurtjes wil je dan voor lief nemen?

Ik bedoel directx / api's / OS'en etc etc. nemen allemaal extra geheugengebruik in. Maar toch zie je weinig windows-programma's geschreven in assembly. En dat is met een reden

Ik bedoel moet je voor de grap maar eens een willekeurige programmeertaal pakken en dan een simpel dialoogboxje op je scherm zetten en dan kijken naar de filesize / memory use.
En dan moet je eens gaan nadenken hoeveel bytes het je zou kosten als je daadwerkelijk direct de vid-kaart zou aanspreken voor het creeeren van een boxje met een background en een border.

Het kan wel efficienter, maar de tijd en effort is het simpelweg niet waard

[Raymond P]

Dadona schreef op zaterdag 20 oktober 2012 @ 21:44:
Snap ik...snap ik. De vraag lijkt mij nu wel beantwoord, maar dan is het nu toch tijd voor het echt educatieve deel. Small scale test weten we, maar nu...met wat gaat de zaak het snelst stuk bij een triljoen entries.
Ik ben echt benieuwd, is het toevoegen en verwijderen van kolommen nu echt iets waar je in principe niet aan moet willen? In ieder geval als het echt om indrukwekkende aantallen entries gaat. Ik ga het zo zelf maar eens uitzoeken.

In dit geval, ervan uitgaand dat de huidige kolom van het datatype TIMESTAMP is, kan je de int die UNIX_TIMESTAMP geeft niet wegschrijven.
Je zal dus een extra kolom moeten maken, tenzij de originele data in een TEXT kolom stond .

Op grote datasets (miljoenen entries) merk je het verschil wel ja. Helemaal als je met partitioning werkt.
Als je met InnoDB en hippe features als bijvoorbeeld compressie bezig bent dan is een kolom toevoegen aan een relatief kleinere dataset al iets wat je niet meer wilt doen.

Over het algemeen is het gewoon handiger om die extra kolom even in een aparte tabel te gooien en vandaaruit te updaten. Helemaal als je op resources moet letten.
De stap ertussen vind ik zelf mooi meegenomen. Zeker bij zware one-time queries.

Verder ook met NMe eens. Geef mij maar een mysql datum, veel flexibeler.

Edit: WOW, mis ik gewoon helemaal page 2!
Nja, misschien vult m'n post nog wat aan.

[Patriot]

Gomez12 schreef op zondag 21 oktober 2012 @ 18:18:
[...]

Hoeveel extra uurtjes wil je dan voor lief nemen?

Ik bedoel directx / api's / OS'en etc etc. nemen allemaal extra geheugengebruik in. Maar toch zie je weinig windows-programma's geschreven in assembly. En dat is met een reden

Ik bedoel moet je voor de grap maar eens een willekeurige programmeertaal pakken en dan een simpel dialoogboxje op je scherm zetten en dan kijken naar de filesize / memory use.
En dan moet je eens gaan nadenken hoeveel bytes het je zou kosten als je daadwerkelijk direct de vid-kaart zou aanspreken voor het creeeren van een boxje met een background en een border.

Het kan wel efficienter, maar de tijd en effort is het simpelweg niet waard

Zo'n reactie was natuurlijk te verwachten. Wat je zegt is natuurlijk niet onwaar, maar het is wel de halve waarheid: Er zijn genoeg situaties waarin er wel degelijk relatief weinig moeite in gestoken hoeft te worden, maar waar men dat zuiver uit zakelijk oogpunt toch niet doen. Wat betreft situaties waarin het de moeite sowieso niet waard is heb je uiteraard gelijk.

[Hydra]

Dat verhaal over een 'kale' driver van 300MB is natuurlijk complete larie.

[Merethil]

Hydra schreef op maandag 22 oktober 2012 @ 10:00:
Dat verhaal over een 'kale' driver van 300MB is natuurlijk complete larie.

Installerbestanden van 299 MB

[Hydra]

Merethil schreef op maandag 22 oktober 2012 @ 10:28:
Installerbestanden van 299 MB

Ja, maar daar zit dan een hoop meuk in, de driver zelf is maar een paar MB.

[Merethil]

Hydra schreef op maandag 22 oktober 2012 @ 10:32:
[...]


Ja, maar daar zit dan een hoop meuk in, de driver zelf is maar een paar MB.

Was wel waar ik op doelde ja....
Meestal hebben die "kale drivers" van dat soort producten allerlei crap om de OEM z'n software aan te bieden aan jou. HP heeft zo'n toffe scanfunctie ingebouwd die ongeveer 1/4e van de tijd werkt met m'n 6500A+, maar zodra m'n huisbaas met z'n iets oudere printer zulke software wil draaien krijgt ie een bluescreen.
Nieuwste variant gedownload, weer gezeik. Printen, weer gezeik. Uiteindelijk maar pc opnieuw geinstalleerd: nog steeds BSOD.

Dan krijg je uiteindelijk dat gefoeter op gigantische driverpakketten en ben ook ik bedroefd genoeg geraakt in een bedrijf die het in mijn ogen best goed deed waardoor ik maar gewoon de standaard windows-driver gebruik.
Zo ook voor alle WLAN kaartjes, bluetooth chipsets en uitbreidkaarten als USB2.0/USB3.0, eSATA en ander spul.

Hoe dan ook: volgens mij is de OP z'n vraag wel beantwoord

[Dadona]

Het is absoluut waar dat de kale driver op zich geen 300MB is, maar de 'kale' wel. Je krijgt geregeld die meuk eromheen mee als je de basisfuncties wil, er zijn geen mooie tune acties of wat. Maar inderdaad, we zijn wel redelijk rond met dit topic.

[Hydra]

Maar wat boeit het dat de download 300MB is? Dat heb je in een paar sec binnen.

[eggied97]

Hydra schreef op maandag 22 oktober 2012 @ 11:04:
Maar wat boeit het dat de download 300MB is? Dat heb je in een paar sec binnen.

niet als je hier op het platteland zit, met een kabeltje dat nauwelijks 550 kb/s trekt

[alienfruit]

Of als je het vanuit Nieuw-Zeeland moet downloaden. Dan duurt het dus 4 uur (350mb)