DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
cd niet bijgeleverd
Als je vragen hebt over PHP/MySQL, dan zit je hier goed met een vaste kliek guru's en een groot aantal regelmatige bezoekers. Beperk je vragen niet tot "hij doet het niet" of "hij geeft een fout" - onze glazen bol is kapot en we willen graag van je weten wát er niet lukt en wélke foutmelding je precies krijgt
Vorige delen:
Via de zoekfunctie
Zie ook:
• PHP Dataverwerking
• Officiële PHP website
• PHP Documentatie
• MySQL Reference Manual
• Yet Another PHP Faq
• PHP Cheat Sheet
• PHP5 Power Programming - boek met uitleg over OOP, Pear, XML, etc
Tutorials:
• W3Schools PHP
• W3Schools SQL
Deze OP en instructies voor nieuw topic: http://wiki.fok.nl/index.php/OP/PHP
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Top GlowMouse! ik ben weer van de partij!
@GlowMouse; het inserten van 1.500.000 records in je tabellen (tags/tag_links) kosten aardig wat tijd, is dat normaal?
@GlowMouse; het inserten van 1.500.000 records in je tabellen (tags/tag_links) kosten aardig wat tijd, is dat normaal?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Meer dan een uurtje mag het niet kosten. Indices tijdelijk uitzetten (niet verwijderen) helpt, storage engine tweaken soms ook.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
@GlowMouse, lol het duurt zekers 8 uur maar dat is dan ook incl indices, bestanden en andere tabellen vullen...
heb zelf totaal geen ervaring met de engine te tweaken dus moet ik gewoon maar even rustig afwachten (tis een slome asus laptop
)
@remi1986; dat is nu geen optie aangezien ik werk met on duplicate key en ruim 250K aan bestanden
maar zet nu wel de queries in een extern bestand zo dat ik als er iets fout is gegaan ik alles zo terug kan zetten zonder weer alle bestanden langs te lopen
heb zelf totaal geen ervaring met de engine te tweaken dus moet ik gewoon maar even rustig afwachten (tis een slome asus laptop
)@remi1986; dat is nu geen optie aangezien ik werk met on duplicate key en ruim 250K aan bestanden
maar zet nu wel de queries in een extern bestand zo dat ik als er iets fout is gegaan ik alles zo terug kan zetten zonder weer alle bestanden langs te lopen
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Pff mijn import is voltooid en heb nu de volgende query; die er volgens mij nog steeds lang over doet.
deze duurt wel 0.3 seconden voor maar 241K tags / 1.500k aan tag_links
Kan ik deze nog verder optimaliseren?
| 1 2 3 4 5 6 7 8 9 10 | SELECT `pix`.*, `pix_tags`.`tag` FROM `pix_tags` LEFT JOIN `pix_tags_links` ON `pix_tags_links`.`tag_id` = `pix_tags`.`tag_id` LEFT JOIN `pix` ON `pix`.`pix_id` = `pix_tags_links`.`pix_id` WHERE `pix_tags`.`tag` LIKE '%cool%' AND `pix`.`adult` = 'n' LIMIT 0,20 |
deze duurt wel 0.3 seconden voor maar 241K tags / 1.500k aan tag_links
Kan ik deze nog verder optimaliseren?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Je doetquote:Op woensdag 16 februari 2011 08:57 schreef Chandler het volgende:
Pff mijn import is voltooid en heb nu de volgende query; die er volgens mij nog steeds lang over doet.
[ code verwijderd ]
deze duurt wel 0.3 seconden voor maar 241K tags / 1.500k aan tag_links
Kan ik deze nog verder optimaliseren?
| 1 | SELECT `pix`.*, |
Wat alle kolommen selecteert. Heb je ze allemaal nodig? Misschien kan je alleen de kolommen selecteren die je echt nodig hebt. Volgens mij scheelt dat toch weer iets.
klopt er zouden een paar kolommen af kunnen maar zou niet weten of dat echt wel een besparing oplevert (extreme besparing)... maar zal het proberen!
-edit-
geprobeerd totaal geen extra preformance winst
-edit-
geprobeerd totaal geen extra preformance winst
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Oke, naja viel te proberen. Je query is eigenlijk ook helemaal niet zo lang en haalt maar 20 records op.quote:
klopt er zouden een paar kolommen af kunnen maar zou niet weten of dat echt wel een besparing oplevert (extreme besparing)... maar zal het proberen!
-edit-
geprobeerd totaal geen extra preformance winst
Vond op http://www.debianadmin.com/top-84-mysql-performance-tips.html nog een lijst met performance tips. Misschien staat er nog wat tussen. Ik weet niet in hoeverre die lijst goed is. Just trying to help
Alle hulp is welkom! en zo leren we allerbeide weer wat meer ik ga het eens doornemen!
ik ga het eens doornemen!
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Met goedgeplaatste indices moet je een eind kunnen komen, volgens mijquote:
Pff mijn import is voltooid en heb nu de volgende query; die er volgens mij nog steeds lang over doet.
[ code verwijderd ]
deze duurt wel 0.3 seconden voor maar 241K tags / 1.500k aan tag_links
Kan ik deze nog verder optimaliseren?
quote:WHERE `pix_tags`.`tag` LIKE '%cool%'
http://gathering.tweakers.net/forum/list_messages/1429432
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Oh, dat had ik nog niet eens gezien, maar dat is helemaal niet te indexeren. Dus met een goede index kun je ook niets oplossen, simpelweg omdat een goede index niet mogelijk is.
Chandler, LIKE %cool% komt op hetzelfde neer als de Dikke Van Dale pakken en alle woorden waar een Q in staat opzoeken. Dat moet je niet willen.
Chandler, LIKE %cool% komt op hetzelfde neer als de Dikke Van Dale pakken en alle woorden waar een Q in staat opzoeken. Dat moet je niet willen.
Weet iemand wat hier fout gaat?
Ik wil dat hij alle data van vandaag en ná vandaag laat zien. Data van voor vandaag dus niet. Hij geeft nu gewoon 0 resultaat.
Als ik inplaats van NOW(), $vandaag = date("d-m-Y"); gebruik en $vandaag achter WHERE invul laat hij álle resultaten zien inplaats van alleen de >=.
Ben ongetwijfeld dom bezig, maar goed, kom er niet uit.
| 1 2 3 | <?php $query = "SELECT agenda_id, agendatitel, agendaplaats, from_unixtime(agendadatum, '%d-%m-%Y') AS datum, agendabeschrijving FROM agenda WHERE agendadatum >= NOW() ORDER BY agenda_id ASC"; ?> |
Ik wil dat hij alle data van vandaag en ná vandaag laat zien. Data van voor vandaag dus niet. Hij geeft nu gewoon 0 resultaat.
Als ik inplaats van NOW(), $vandaag = date("d-m-Y"); gebruik en $vandaag achter WHERE invul laat hij álle resultaten zien inplaats van alleen de >=.
Ben ongetwijfeld dom bezig, maar goed, kom er niet uit.
"My name is Emery and primarily I make noises - and ideas".
Hij zet de datum als unix_timestamp in een varchar veld.quote:
Werken datum velden in MySQL niet in Y-m-d formaat?
"My name is Emery and primarily I make noises - and ideas".
dan moet je
gebruiken denk ik aangezien het anders geen timestamp is
| 1 2 3 | <?php strtotime(date("Y-m-d")); ?> |
gebruiken denk ik aangezien het anders geen timestamp is
Overigs doe je
en
moet dat dan niet datum zijn i.p.v. agendadatum?
| 1 | from_unixtime(agendadatum, '%d-%m-%Y') AS datum |
en
| 1 | WHERE agendadatum >= NOW() |
moet dat dan niet datum zijn i.p.v. agendadatum?
Nee, want als je daar agendadatum van maakt gaat hij vervolgens WHERE doen op de unixtimestamp die al is omgezet volgens mij.quote:
Overigs doe je
[ code verwijderd ]
en
[ code verwijderd ]
moet dat dan niet datum zijn i.p.v. agendadatum?
"My name is Emery and primarily I make noises - and ideas".
Klopt idd. Maar dan kan je toch gewoon een timestamp maken met strtotime of mktime en dan kijken welke varchar daar boven zit?
Ik heb zelf even een testtabel gemaakt met een varchar waar ik 2 timestamps in heb gezet.
Die van 1-1-2011 en 10-10-2011. Een in de toekomst en één in het verleden.
Als ik dan
krijg ik ze beide
en met >= niks
Ik heb zelf even een testtabel gemaakt met een varchar waar ik 2 timestamps in heb gezet.
Die van 1-1-2011 en 10-10-2011. Een in de toekomst en één in het verleden.
Als ik dan
| 1 | SELECT from_unixtime(timestamp, '%d-%m-%Y') AS datum FROM test WHERE timestamp <= NOW() |
krijg ik ze beide
en met >= niks
Op
Een unix timestamp is gewoon een getal, kan dus prima in een INT-veldquote:Op woensdag 16 februari 2011 14:52 schreef Emery het volgende:
[..]
Hij zet de datum als unix_timestamp in een varchar veld.
En verder zou ik de datum gewoon als timestamp uit de database halen. Je kunt op een veel later moment (namelijk als je alles op het scherm zet) nog wel bepalen hoe die datum precies op het scherm moet verschijnen.
Ik heb je topic meerdere keren door gelezen maar kan niet vinden wat ik fout doe!quote:Op woensdag 16 februari 2011 10:33 schreef GlowMouse het volgende:
[..]
http://gathering.tweakers.net/forum/list_messages/1429432
Daarbij komt dat ik niets anders weet om te zoeken op tags, en aangezien ik dat wel wil heb ik dit geprobeerd. Kun je mij wijzen op,mijn fouten zodat ik er van kan leren?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Vergelijk mijn queries maar met jouw queries. Ik heb per tag één id.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Dat heb ik ook, maar ik heb meerdere tags per plaatje
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Simpel tooltje om timestamp om te zetten naar utc+1
http://tools.pcextreme.nl/?page=date
http://tools.pcextreme.nl/?page=date
"Op Fok! val je pas op als je normaal bent." -mazaru
Dat sluit mijn db-opzet niet uit.quote:
Dat heb ik ook, maar ik heb meerdere tags per plaatje
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Klopt, maar wijs mij dan op het gene wat ik fout doe want nu snap ik er de balle van....
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Jij koppelt meer tags aan één tag-id.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
nee, ook niet. Ik gebruik precies de tabellen die jij ook gebruikt in je voorbeeld op tweakers! tenzij je het hebt over de 'link' tabel tussen mijn plaatjes en de tags... maar dat is ook nodig voor mijn systeem want aan 1 tag per plaatje heb ik weinig!
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
waarom gebruik je dan LIKE '%cool%' en niet ='cool'?
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
omdat ik eventueel ook tags wil pakken die een deel van het woord bevatten!, of denk je dat dat over de top is?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
oh, je moet altijd met hele tags werken
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
LOL, maar heb je ook een idee of ik dit eventueel voor delen van tags kan gebruiken of moet ik dan over een heel andere opzet gaan nadenken? zo niet dan houden we het op hele!
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
quote:
Chandler, LIKE %cool% komt op hetzelfde neer als de Dikke Van Dale pakken en alle woorden waar een Q in staat opzoeken. Dat moet je niet willen.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Hmm. Ik weet niet wat ik heb gedaan maar vanmiddag deed mijn script nog wat hij moest doen (gewoon de datum die is ingevuld in het formulier naar unix_timestamp omzetten en in de database pleuren) maar opeens (volgens mij heb ik niks veranderd?) doet hij het alleen nog maar de datum van vandaag in de database zetten.
Die variabelen $maand, $dag en $jaar verkrijgt hij door $maand = $_POST['maand']; et cetera.
| 1 2 3 4 5 6 7 8 9 10 | <?php $mktijd = mktime($maand, $dag, $jaar); $sql= "INSERT INTO agenda (agendatitel, agendaplaats, agendadatum, agendabeschrijving) VALUES ('" . mysql_real_escape_string($agendatitel) . "', '" . mysql_real_escape_string($agendaplaats) . "', '" . mysql_real_escape_string($mktijd) . "', '" . mysql_real_escape_string($agendabeschrijving) . "')"; ?> |
Die variabelen $maand, $dag en $jaar verkrijgt hij door $maand = $_POST['maand']; et cetera.
"My name is Emery and primarily I make noises - and ideas".
Lijkt me sterk dat het daaraan ligt? Hij deed het vanmiddag gewoon goed en toen heb ik ook geen 0,0,0 gebruikt. Overigens is nu opeens de webserver van de website waar ik aan het testen ben down. Godver.quote:
Op
"My name is Emery and primarily I make noises - and ideas".
Enigste wat me opviel. Verder weet ik het ook nietquote:
[..]
Lijkt me sterk dat het daaraan ligt? Hij deed het vanmiddag gewoon goed en toen heb ik ook geen 0,0,0 gebruikt. Overigens is nu opeens de webserver van de website waar ik aan het testen ben down. Godver.
. [/newb]Lijkt me dat er vandaag al iets raars was met de server omdat hij nu down is. Dus ik denk dat het daaraan ligt. Als het eerder nooit een probleem was.
Ik denk dat er iets fout gaat in de POST want als ik in mijn 'uw bericht is toegevoegd'-message $dag, $maand en $jaar echo krijg ik gewoon $dag, $maand en $jaar te zien in plaats van de waardes die zijn ingevuld. Apart.
"My name is Emery and primarily I make noises - and ideas".
Wat geeft vardump($mktijd) en wat is de unixtimestamp van vandaag?
Hm, het is vast een fout in de postwaarden doorsturen dan.
Hm, het is vast een fout in de postwaarden doorsturen dan.
Oké, dat is het ook niet. Het ligt aan mijn wijzigingsformulier denk ik. Hij voegt ze nu prima toe, zodra ik in mijn wijzigingsformulier de datum aanpas slaat hij hem niet goed op in de database. Als ik daar $maand e.d. echo laat hij overigens wél de goede (nieuwe) data zien na het opslaan. Dus dan gaat er iets fout bij de mktime() om het in de database op te slaan denk ik. Als hij geen waarden vindt in de variabelen bij mktime($maand, $blabla), ziet hij het dan gewoon als mktime()? Want als hij dat doet kan het wel kloppen dat hij vandaag in de database zet.
"My name is Emery and primarily I make noises - and ideas".
vardump(mktime()) en je hebt je antwoord.
quote:mktime() returns the Unix timestamp of the arguments given. If the arguments are invalid, the function returns FALSE (before PHP 5.1 it returned -1).
Ik weet het denk ik. Als je mktime() dus false is of een foute waarde heeft dan komt er automatisch vandaag in de database omdat het veld niet leeg mag zijn ofzo?
if ($mktijd) { voer in }
else { error }
if ($mktijd) { voer in }
else { error }
Jup. Krijg de unixtimestamp van dit moment als ik dat doe. Géén idee waarom hij het niet doet maar in ieder geval weet ik nu waar de fout zit.
"My name is Emery and primarily I make noises - and ideas".
Et voila. Blijkbaar maakt het hem bij een INSERT niet uit dat er geen 0, 0, 0, staat in de mktime() en bij een UPDATE wel.. 0, 0, 0 toegevoegd in mktime() en hij werkt.
!
!
"My name is Emery and primarily I make noises - and ideas".
Haha ongeveer wel ja. Maar toen dacht ik nog dat het aan de INSERT lag. En niet aan het update script. Nou ja, bedankt voor het meedenken!quote:
Haha, dus mijn eerste opmerking was de fout.
"My name is Emery and primarily I make noises - and ideas".
