Toon posts:

[mysqll/php] 29.000 rows updaten

Pagina: 1
Acties:

Onderwerpen


  • Bananenspin
  • Registratie: December 2008
  • Laatst online: 13-03 22:09
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]

HOI.


  • Merethil
  • Registratie: December 2008
  • Laatst online: 06:01
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
  • Registratie: April 2009
  • Laatst online: 05-03 12:10
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
  • Registratie: December 2002
  • Laatst online: 08:42
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!
  • Registratie: April 2000
  • Niet online
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
  • Registratie: April 2005
  • Laatst online: 00:40

Nic

Vrij

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:
1
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
  • Registratie: September 2007
  • Laatst online: 15-03 18:29
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. :P

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

De CSL/OT kroeg !


  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-03 13:05

NMe

Quia Ego Sic Dico.

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]

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 23-07-2021
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
  • Registratie: Februari 2004
  • Laatst online: 04-03 13:05

NMe

Quia Ego Sic Dico.

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

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • Dadona
  • Registratie: September 2007
  • Laatst online: 15-03 18:29
Wie weet moet dit op een Raspberry Pi gebeuren zonder dat de gebruikers er iets van merken? :P Maar inderdaad, een UPDATE-SELECT van deze vorm is op normale hardware zo gebeurd.

De CSL/OT kroeg !


  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-03 13:05

NMe

Quia Ego Sic Dico.

Hoezo UPDATE-SELECT?

MySQL:
1
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. 8)7

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • Cartman!
  • Registratie: April 2000
  • Niet online
Persoonlijk heb ik ook liever datetime-velden in m'n tabellen, direct leesbaar en mbv. DateTime kun je t formatten hoe je wilt :)

  • Bananenspin
  • Registratie: December 2008
  • Laatst online: 13-03 22:09
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. :P
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? :P 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.

HOI.


  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-03 13:05

NMe

Quia Ego Sic Dico.

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.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • Dadona
  • Registratie: September 2007
  • Laatst online: 15-03 18:29
NMe schreef op zaterdag 20 oktober 2012 @ 21:26:
Hoezo UPDATE-SELECT?

MySQL:
1
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. 8)7
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 :P. 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]

De CSL/OT kroeg !


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 23-07-2021
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 :P.
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
  • Registratie: September 2007
  • Laatst online: 15-03 18:29
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. :P
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. :)

De CSL/OT kroeg !


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 23-07-2021
Dadona schreef op zaterdag 20 oktober 2012 @ 21:44:
met wat gaat de zaak het snelst stuk bij een triljoen entries. :P
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
  • Registratie: September 2007
  • Laatst online: 15-03 18:29
Ah, ik ben dus niet helemaal gek. Bedankt. :)

De CSL/OT kroeg !


  • Bananenspin
  • Registratie: December 2008
  • Laatst online: 13-03 22:09
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.

HOI.


  • NMe
  • Registratie: Februari 2004
  • Laatst online: 04-03 13:05

NMe

Quia Ego Sic Dico.

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?

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • Bananenspin
  • Registratie: December 2008
  • Laatst online: 13-03 22:09
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.

HOI.


  • Zoijar
  • Registratie: September 2001
  • Niet online

Zoijar

Because he doesn't row...

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
  • Registratie: December 2008
  • Laatst online: 13-03 22:09
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.

HOI.


  • Dadona
  • Registratie: September 2007
  • Laatst online: 15-03 18:29
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.

De CSL/OT kroeg !


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 23-07-2021
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
  • Registratie: Februari 2004
  • Laatst online: 04-03 13:05

NMe

Quia Ego Sic Dico.

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. ;)

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 23-07-2021
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
  • Registratie: December 2004
  • Laatst online: 24-03 17:12

Patriot

Fulltime #whatpulsert

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.

de Tweakers-cookiewall is illegaal


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 23-07-2021
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
  • Registratie: September 2006
  • Laatst online: 07:23
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. :P
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 :9.

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.

- knip -


  • Patriot
  • Registratie: December 2004
  • Laatst online: 24-03 17:12

Patriot

Fulltime #whatpulsert

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.

de Tweakers-cookiewall is illegaal


  • Hydra
  • Registratie: September 2000
  • Laatst online: 24-03 08:31
Dat verhaal over een 'kale' driver van 300MB is natuurlijk complete larie.

https://niels.nu


  • Merethil
  • Registratie: December 2008
  • Laatst online: 06:01
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
  • Registratie: September 2000
  • Laatst online: 24-03 08:31
Ja, maar daar zit dan een hoop meuk in, de driver zelf is maar een paar MB.

https://niels.nu


  • Merethil
  • Registratie: December 2008
  • Laatst online: 06:01
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.... :P
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 :P

  • Dadona
  • Registratie: September 2007
  • Laatst online: 15-03 18:29
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. :)

De CSL/OT kroeg !


  • Hydra
  • Registratie: September 2000
  • Laatst online: 24-03 08:31
Maar wat boeit het dat de download 300MB is? Dat heb je in een paar sec binnen.

https://niels.nu


  • eggied97
  • Registratie: Mei 2011
  • Laatst online: 24-03 13:49

eggied97

01000101

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 :/

student - progger - beunen


  • alienfruit
  • Registratie: Maart 2003
  • Laatst online: 04:50

alienfruit

the alien you never expected

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


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee