1 |
dat werkt jaquote:Op woensdag 1 maart 2006 14:52 schreef the_disheaver het volgende:
of:
[ code verwijderd ]
of
[ code verwijderd ]
of:
[ code verwijderd ]
uitleg: je hebt geen aanhalingstekens voor en na de value-waarde. Alleen een aanhalingsteken welke het einde van de echo weergeeft.
Dus of enkele aanhalingstekens waardoor je de dubbele niet te hoeft escapen, of dubbele aanhalingstekens, en de dubbele aanhalingstekens voor het HTML escapen. Of alleen voor de echoén van de value php gebruik, de rest in normale html (zonder te echo'en)
1 |
1 2 | extension=php_mysql.dll <- enabled |
1 2 3 | {elks teken incl newline} </div> |
1 |
1 2 3 | <div id="MCaddtion"> |
Dus /ene regel.*volgende regel/s werkt over meerdere regels.quote:s (PCRE_DOTALL)
If this modifier is set, a dot metacharacter in the pattern matches all characters, including newlines. Without it, newlines are excluded. This modifier is equivalent to Perl's /s modifier. A negative class such as [^a] always matches a newline character, independent of the setting of this modifier.
quote:Op dinsdag 28 februari 2006 14:52 schreef user931989 het volgende:
Ik heb een HTML-documentje, dat uit een rss-feed geparsed wordt.
In die rss-feed staat echter voor elke ' en " een backslash.
Nu include ik dat html-document in een php, maar het lukt mij niet om die backslashes weg te krijgen.
Normaal zou ik dit met str_replace doen, maar door die include lukt dat niet.
Hoe kan dit wel?
quote:Op dinsdag 28 februari 2006 15:09 schreef ikke_ook het volgende:
door die html-file in te lezen met fopen en hem dan als string te behandelen?
Kan niemand mij helpen?quote:Op dinsdag 28 februari 2006 15:17 schreef user931989 het volgende:
Als ik hem met fopen inlees krijg ik dit te zien:
Resource id #2
misschien komt dat doordat het in hetzelfde php-document ook verwerkt wordt
file_get_contentsquote:Op woensdag 1 maart 2006 20:08 schreef user931989 het volgende:
Kan niemand mij helpen?
helemaal afhankelijk van wat je doet...quote:Op donderdag 2 maart 2006 02:26 schreef Tijn het volgende:
Wat is een beetje normale tijd waarin een script wordt uitgevoerd?
Of beter gezegd, als een script er langer dan hoeveel micro/milliseconden over doet, moet ik de boel nodig eens optimaliseren?
Nee.quote:Op donderdag 2 maart 2006 14:46 schreef blieblie het volgende:
ff domme vraag, maar waarom worden er in de bestandsnamen van includes de subextensie "inc" gebruikt. Dus dat je krijgt config.inc.php ipv. config.php .
Zitten daar meer voordelen aan dan alleen het kunnen herkennen van includes aan de bestandsnaam?
Dat hangt af van de machine waarop je script draait, de snelheid van de databaseserver waarmee je een verbinding hebt, en zo nog een paar honderd variabelen. Als je script bij normaal gebruik (geen zware zoekactie oid) merkbaar traag is (~ >100 ms) dan wordt het misschien tijd om uit te zoeken hoe dat komt.quote:Op donderdag 2 maart 2006 02:26 schreef Tijn het volgende:
Wat is een beetje normale tijd waarin een script wordt uitgevoerd?
Of beter gezegd, als een script er langer dan hoeveel micro/milliseconden over doet, moet ik de boel nodig eens optimaliseren?
Ben nog totaal niet thuis in PHP maar het lijkt mij dat dat soort dingen gewoon van de PC van de gebruiker afhangt? Op jouw AMD 3000+ zal het ws wel sneller dan 7ms zijn maar als je nog op een 1000+ draait...quote:Op donderdag 2 maart 2006 17:29 schreef Tijn het volgende:
Ik snap dat het van vanalles afhangt, maar ik heb werkelijk geen idee wat "normaal" is. Ik heb een openingpagina gemaakt met 2 queries en wat for-lussen die zichzelf in 7 ms op het scherm zet. Ik vroeg me af of dat redelijk is. Maar ik begrijp dat je pas bij merkbare traagheid actie moet ondernemen en dat er geen algemene regel is in de trant van "als je pagina niet binnen 10 ms rendert is er wat mis" ofzo.
Nee. PHP draait op de server.quote:Op donderdag 2 maart 2006 17:33 schreef DaFan het volgende:
[..]
Ben nog totaal niet thuis in PHP maar het lijkt mij dat dat soort dingen gewoon van de PC van de gebruiker afhangt? Op jouw AMD 3000+ zal het ws wel sneller dan 7ms duren maar als je nog op een 1000+ draait...
Foutmelding die ik dus krijg is:quote:Op woensdag 1 maart 2006 18:35 schreef DaFan het volgende:
Korte vraag, kheb de FAQs ed al doorgelezen en het idee is me duidelijk, maar ik krijg het niet aan de praat.
Het gaat om het áan de praat krijgen van MySQL functions in PHP 5 (Dit).
Nu heb ik gevolgd wat er allemaal staat, maar mysql_connect weigert te werken.
Voor de goede orde, mijn map waar php is geinstalleerd is:
1 C:/php
php.ini staat in de WINDOWS map op de C:/schijf en daar zijn de volgende dingen gewijzigd:
1
2extension_dir = "C:\php"
extension=php_mysql.dll <- enabled
De libmysql.dll is toegevoegd én aan de Windows/system map en ik heb via de Omgevingsvariabelen C:/php als PATH aangegeven.
Kan iemand mij simpel en stap voor stap uitleggen wat er moet gebeuren binnen PHP 5 om MySQL functions aan de praat te krijgen?
Bedankt, en excuses dat ik er niet uitkom
1 |
15x ongeveerquote:Op donderdag 2 maart 2006 17:56 schreef JeRa het volgende:
@DaFan
Don't slap me with a trout, maar heb je de Apache webserver opnieuw gestart?
Waarom download je geen compleet pakket zoals bijvoorbeeld appserv? Dan hoef je niets te configureren. Installeren en draaien maarquote:
Heu das wel verdomde handig. Als je die installed werken ze dan direct met elkaar ? Dus PHP in Apache en MySQL zonder dat je ini's hoeft te verschuiven enzo?quote:Op donderdag 2 maart 2006 18:39 schreef Swetsenegger het volgende:
[..]
Waarom download je geen compleet pakket zoals bijvoorbeeld appserv? Dan hoef je niets te configureren. Installeren en draaien maar
Jaquote:Op donderdag 2 maart 2006 18:43 schreef DaFan het volgende:
[..]
Heu das wel verdomde handig. Als je die installed werken ze dan direct met elkaar ? Dus PHP in Apache en MySQL zonder dat je ini's hoeft te verschuiven enzo?
1 2 3 4 5 6 | $query="SELECT * FROM produkten WHERE product_menu=".$_GET['id']." ORDER BY first_price ASC, product_id DESC"; ?> |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | $query="SELECT oc.number, p.articelcode, p.name, oc.giftwrap, p.first_price, p.second_price FROM orders o INNER JOIN order_content oc ON oc.order_id = o.order_id INNER JOIN produkten p ON p.product_id = oc.product_id INNER JOIN users u ON u.user_id = o.user_id WHERE o.order_id =".$_GET['order']." && u.name='".$_SESSION['name']."'"; ?> |
php.ini?quote:Op donderdag 2 maart 2006 21:02 schreef H4ze het volgende:
Ik zoek me een ongeluk, maar waar kan ik in godsnaam het maximale aantal connecties van mysql aanpassen?Op internet vind ik steeds /etc/my.cnf, maar ik ben geloof ik hardstikke blind....
Ik ben iets aan 't maken met mysql en JSP/Servlets, dus denk niet dat de php.ini er veel mee te maken heeft. Thnx voor 't snelle antwoord iig. Maar je moet toch gewoon via de mysql commandline iets kunnen opgeven?quote:
Nee dan heeft php er niets mee te makenquote:Op donderdag 2 maart 2006 21:08 schreef H4ze het volgende:
[..]
Ik ben iets aan 't maken met mysql en JSP/Servlets, dus denk niet dat de php.ini er veel mee te maken heeft. Thnx voor 't snelle antwoord iig. Maar je moet toch gewoon via de mysql commandline iets kunnen opgeven?
jep al gelezenquote:Op donderdag 2 maart 2006 21:11 schreef Swetsenegger het volgende:
[..]
Nee dan heeft php er niets mee te maken
http://dev.mysql.com/doc/refman/4.1/en/too-many-connections.html Staat hier wat bij?
en als je my.cnf file gewoon opent?quote:Op donderdag 2 maart 2006 21:12 schreef H4ze het volgende:
[..]
jep al gelezen![]()
Stond in de reacties wel 1 iets bij:
You can increase this value in main config file (e.g., /etc/my.cnf) using this syntax:
[mysqld]
set-variable=max_connections=250
Dus ik heb in de commandline '--set-variable=max_connections=250'. Hij gaf dan geen error ofzo, maar ook niet dat het nu veranderd was....
Nou, dan weet ik niet wat je doet, want appserv is 3 keer next klikken, je files in de www directory zetten en openen met localhost/filename.phpquote:Op donderdag 2 maart 2006 21:18 schreef DaFan het volgende:
Leuk en aardig dat AppServ maar het werkt nog steeds niet. En nu kan ik totaal niet vinden waar ik in mn MySQL command kan komen. MySQLAdmin opent in DOS en is in 1 sec weer weg
Dus nu kan ik helemaal niks meer
Eigenlijk alles waar op gefilterd of gesorteerd wordt. Dus de kolommen die in de join condities worden gebruikt, maar ook die in de where staan. Als er geen idex voor bestaat dan moet de hele tabel gescanned worden.quote:Op donderdag 2 maart 2006 21:01 schreef Swetsenegger het volgende:
Mijn boerenverstand zegt van alle FK's in alle tabellen dus orders.user_id, order_content.order_id en order_content.product_id.
Maar... klopt dat wel? En kan iemand ook helder onder woorden brengen waarom?
Oke, dus als stelregel kan je zeggen dat je altijd(?) indices moet maken op foreign keys EN op kolommen welke (vaak) in where statements worden gebruikt, correct?quote:Op donderdag 2 maart 2006 21:36 schreef SuperRembo het volgende:
[..]
Eigenlijk alles waar op gefilterd of gesorteerd wordt. Dus de kolommen die in de join condities worden gebruikt, maar ook die in de where staan. Als er geen idex voor bestaat dan moet de hele tabel gescanned worden.
Niet bij álle foreign keys, maar het is een goede vuistregel ja. Voorbeeldje waarbij het niet moet; als je voor een fotoalbum drie groottes van een bepaalde foto hebt kun je die drie groottes in één record laten verwijzen naar drie foreign records, maar daar hoeft in principe helemaal geen index op omdat je daar nooit op selecteert of sorteert.quote:Op donderdag 2 maart 2006 21:41 schreef Swetsenegger het volgende:
[..]
Oke, dus als stelregel kan je zeggen dat je altijd(?) indices moet maken op foreign keys EN op kolommen welke (vaak) in where statements worden gebruikt, correct?
In álle gevallen worden INSERTs trager door indices, en als het goed is kan MySQL zelf prima bepalen of het een index gebruikt of nietquote:Ik las namelijk op mysql.org dat het in sommige gevallen trager kan worden door indices.
Nee ok, alleen op kolommen waarop je selecteert of sorteert is een betere benaming.quote:Op donderdag 2 maart 2006 21:55 schreef JeRa het volgende:
[..]
Niet bij álle foreign keys, maar het is een goede vuistregel ja. Voorbeeldje waarbij het niet moet; als je voor een fotoalbum drie groottes van een bepaalde foto hebt kun je die drie groottes in één record laten verwijzen naar drie foreign records, maar daar hoeft in principe helemaal geen index op omdat je daar nooit op selecteert of sorteert.
Van mysql.org:quote:In álle gevallen worden INSERTs trager door indices, en als het goed is kan MySQL zelf prima bepalen of het een index gebruikt of nietdus wat dat betreft zal het niet trager worden.
MySQL staat nou niet echt goed bekend om z'n query optimalisatie kwaliteiten.quote:Op donderdag 2 maart 2006 21:55 schreef JeRa het volgende:
en als het goed is kan MySQL zelf prima bepalen of het een index gebruikt of niet
In jouw voorbeeld zie ik één query die alle rows aandoet en die sorteert op first_price; die zou je prima kunnen indexeren.quote:Op donderdag 2 maart 2006 22:05 schreef Swetsenegger het volgende:
Maar ja, in bovenstaand voorbeeld heb ik regelmatig ALLE product rows nodig. Zijn indexes dan aan te raden of niet?
Dat weet ik, ik ga er altijd vanuit dat ze dat in de toekomst nog kunnen verbeteren terwijl de queries hetzelfde blijven. Als het een probleem wordt schakel ik over op een andere DBMS die dat wel kan bepalenquote:Op donderdag 2 maart 2006 22:10 schreef SuperRembo het volgende:
[..]
MySQL staat nou niet echt goed bekend om z'n query optimalisatie kwaliteiten.
First price heb ik inderdaad nu geindexeerd.quote:Op donderdag 2 maart 2006 23:14 schreef JeRa het volgende:
[..]
In jouw voorbeeld zie ik één query die alle rows aandoet en die sorteert op first_price; die zou je prima kunnen indexeren.
[..]
Dat weet ik, ik ga er altijd vanuit dat ze dat in de toekomst nog kunnen verbeteren terwijl de queries hetzelfde blijven. Als het een probleem wordt schakel ik over op een andere DBMS die dat wel kan bepalen
Laat eens zien?quote:Op vrijdag 3 maart 2006 11:04 schreef Swetsenegger het volgende:
Ik heb een mooie query van Super Rembo, welke 3 laatste records per catagorie uit de database trekt.
Alleen duurt deze query tussen de 15(!) en 0.0003 seconden. De eerste keer doet hij er meestal heel lang over, de tweede keer korter.
Ik mag toch aannemen dat dat aan de hoster ligt?
De Query?quote:
1 2 3 4 5 6 7 | FROM genre g INNER JOIN ad a ON a.genre = g.genre_id INNER JOIN ad a2 ON a2.genre = g.genre_id AND a.ad_id <= a2.ad_id GROUP BY a.ad_id HAVING COUNT(a2.ad_id) <= 3 ORDER BY g.genre_id, a.ad_id DESC |
Wat anders?quote:
Dit is een mooi voorbeeld van een query die géén indices gebruikt maar de tweede keer snel wordt door het gebruik van de query cache op de server. Ik zie zo even niet waarom hij ze niet gebruikt.quote:Op vrijdag 3 maart 2006 11:04 schreef Swetsenegger het volgende:
Alleen duurt deze query tussen de 15(!) en 0.0003 seconden. De eerste keer doet hij er meestal heel lang over, de tweede keer korter.
Ja, als ik de GROUP BY aanpas naar bv a.title is hij de eerste keer weer traag.quote:Op vrijdag 3 maart 2006 14:31 schreef JeRa het volgende:
[..]
Dit is een mooi voorbeeld van een query die géén indices gebruikt maar de tweede keer snel wordt door het gebruik van de query cache op de server. Ik zie zo even niet waarom hij ze niet gebruikt.
Als het goed is zou je door iets te veranderen in één van de tabellen de query uit de query cache kunnen halen, is hij dan weer zo traag?
ongeveer 2000 records in de ad table, 19 in de genre tabel en een stuk of 100 in de user tabel. ALlemaal niet erg spannendquote:Op vrijdag 3 maart 2006 14:48 schreef Scorpie het volgende:
Hm ik zie zo 1,2,3 niet in waarom hij zo lang moet laden...heel apart. Hoeveel data bevatten de tabellen?
Om voor testing purposes de query cache eventjes te omzeilen zou je SQL_NO_CACHE kunnen gebruiken, zie deze pagina.quote:Op vrijdag 3 maart 2006 14:49 schreef Swetsenegger het volgende:
[..]
Ja, als ik de GROUP BY aanpas naar bv a.title is hij de eerste keer weer traag.
Ik vreesde ook al dat de query daadwerkelijk traag is en de tweede keer uit cache komt
Je GROUP BY is trouwens niet helemaal goed. Alle velden die je in de SELECT gebruikt en die je niet in een aggregate functie hebt staan, moeten in de GROUP BY worden opgenomen. MySQL accepteerd het wel als je dat niet doet, maar dat kan tot onvoorspelbare resultaten leiden. Zo zou het moeten:quote:Op vrijdag 3 maart 2006 11:13 schreef Swetsenegger het volgende:
[..]
De Query?
[ code verwijderd ]
-edit-
indices op a.ad_id (PK), a.genre, g.genre_id (PK)
1 |
1 |
De aggregate functie is... het optel gebeuren?quote:Op vrijdag 3 maart 2006 15:40 schreef SuperRembo het volgende:
[..]
Je GROUP BY is trouwens niet helemaal goed. Alle velden die je in de SELECT gebruikt en die je niet in een aggregate functie hebt staan, moeten in de GROUP BY worden opgenomen. MySQL accepteerd het wel als je dat niet doet, maar dat kan tot onvoorspelbare resultaten leiden. Zo zou het moeten:
[ code verwijderd ]
Eventueel zou je alleen de PK's op kunnen nemen. Dan zijn de resultaten voorspelbaar maar misschien is het ietsje sneller
[ code verwijderd ]
Hier begrijp ik niets van.quote:Op vrijdag 3 maart 2006 17:23 schreef SuperRembo het volgende:
Ik weet niet in welke volgorde MySQL die joins uitvoert. Met een beetje pech begint MySQL met de join van ad op ad. Die geeft 2000 * 2000 / 2 = 2000000 rows.
Dat dacht ik ook.quote:Op vrijdag 3 maart 2006 18:06 schreef JeRa het volgende:
Zelfs dan zou het niet zó lang mogen duren, toch? Een query op een tabel met 10.000 rows die ik op zichzelf laat joinen is in een fractie van een seconde gedaan.
1 2 3 4 5 | FROM ad WHERE genre=1 ORDER BY ad_id DESC LIMIT 3 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | $queryMain="SELECT * FROM genre"; $resultMain=mysql_query($queryMain); while($rowMain=mysql_fetch_assoc($resultMain)){ $querySub="SELECT title, ad_id, image, price FROM ad WHERE genre=".$rowMain['genre_id']." ORDER BY ad_id DESC LIMIT 3"; $resultSub=mysql_query($querySub); while($rowSub=mysql_fetch_assoc($resultSub)){ // doe iets } } ?> |
Ik moet toe geven dat het stiekum toch een draak van een query is. Ik heb ff een testje gedraaid met een tabel met 10000 rows... daarmee legde MySQL m'n pc 16 minuten plat. MSSQL deed het met dezelfde data in 42 seconden.quote:Op vrijdag 3 maart 2006 19:28 schreef Swetsenegger het volgende:
Het gadverdamme ik haat een frontpage waarop 20 queries gedraaid worden. Ik vond SuperRembo's oplossing juist zo'n geile query
Maar hij zag er wel heel cool uit en LIJKT veel sneller dan 20 queriesquote:Op vrijdag 3 maart 2006 21:18 schreef SuperRembo het volgende:
[..]
Ik moet toe geven dat het stiekum toch een draak van een query is. Ik heb ff een testje gedraaid met een tabel met 10000 rows... daarmee legde MySQL m'n pc 16 minuten plat. MSSQL deed het met dezelfde data in 42 seconden.
En wat geeft de EXPLAIN van die query? Dat levert meestal wel info waarmee je kunt kijken wat er lang duurt.quote:Op vrijdag 3 maart 2006 11:13 schreef Swetsenegger het volgende:
[..]
De Query?
[ code verwijderd ]
-edit-
indices op a.ad_id (PK), a.genre, g.genre_id (PK)
Of ik begrijp dat explain gewoon niet, of ik doe wat fout.quote:Op vrijdag 3 maart 2006 21:34 schreef Light het volgende:
[..]
En wat geeft de EXPLAIN van die query? Dat levert meestal wel info waarmee je kunt kijken wat er lang duurt.
1 2 3 4 | g ALL PRIMARY NULL NULL NULL 19 Using temporary; Using filesort a ref PRIMARY,genre genre 4 g.genre_id 24 Using where a2 ref PRIMARY,genre genre 4 g.genre_id 24 Using where |
Hij is lastigquote:Op vrijdag 3 maart 2006 21:57 schreef Swetsenegger het volgende:
[..]
Of ik begrijp dat explain gewoon niet, of ik doe wat fout.
Anyway, dit komt eruit
[ code verwijderd ]
quote:Op zaterdag 4 maart 2006 10:49 schreef Light het volgende:
[..]
Hij is lastig
Maar als je nou de key genre in de tabel ad eens aanpast er daar ad_id als tweede index bij zet, wordt het dan sneller?
MySQL heeft de leuke eigenschap dat het maar 1 key (index dus) kan gebruiken.
Ja, ik bedoelde dan ook een index op meerdere kolommen, namelijk genre en ad_id.quote:Op zaterdag 4 maart 2006 11:04 schreef Swetsenegger het volgende:
[..]
ad_id is de PK, die is toch al index?
dus de index op genre zou het juist trager maken ipv sneller?quote:Op zaterdag 4 maart 2006 11:14 schreef Light het volgende:
[..]
Ja, ik bedoelde dan ook een index op meerdere kolommen, namelijk genre en ad_id.
Ik bedoelde dus een index op (genre, ad_id). Maar je zou ook de index op genre eens weg kunnen halen om te kijken of dat effect heeft. Ik vermoed dat het wel merkbaar is, omdat er dan een index gebruikt kan worden bij de group by. Lijkt mij.quote:Op zaterdag 4 maart 2006 11:32 schreef Swetsenegger het volgende:
[..]
dus de index op genre zou het juist trager maken ipv sneller?
Ah zoquote:Op zaterdag 4 maart 2006 11:38 schreef Light het volgende:
[..]
Ik bedoelde dus een index op (genre, ad_id). Maar je zou ook de index op genre eens weg kunnen halen om te kijken of dat effect heeft. Ik vermoed dat het wel merkbaar is, omdat er dan een index gebruikt kan worden bij de group by. Lijkt mij.
Als ik hier lokaal ga testen dan is die query nog best snel. Maar ik heb natuurlijk geeen 2000 rows in een ad tabelquote:Op zaterdag 4 maart 2006 12:14 schreef Swetsenegger het volgende:
[..]
Ah zo
Nee, dat heeft geen effect want ik ben juist met indexes gaan klooien omdat die query zo traag was
Ik heb nu dus die query herschreven zoals op de vorige pagina, en ondanks dat ik dus 20 queries draai, vliegt dit het scherm op.
Mooi is het niet, effectief wel. Daarom vroeg ik al vanaf welke MySQL versie subqueries ondersteunt worden (4.1) maar er draait 4.0 op de server.
Dat klopt, de query was in eerste instantie ook snel genoeg. Ik was er ook zeer content mee.quote:Op zaterdag 4 maart 2006 12:41 schreef Light het volgende:
[..]
Als ik hier lokaal ga testen dan is die query nog best snel. Maar ik heb natuurlijk geeen 2000 rows in een ad tabel
Ik heb hier nog een tabel kunnen vinden met 2000+ rows, met items in verschillende groepen. En daar kan ik best per groep de laatste 3 items uithalen met jouw query, kost maximaal ongeveer 0.02 seconden (op mijn pc).quote:Op zaterdag 4 maart 2006 12:50 schreef Swetsenegger het volgende:
[..]
Dat klopt, de query was in eerste instantie ook snel genoeg. Ik was er ook zeer content mee.
Maar als ik SuperRembo's reken sommetje volg, neemt met een verdubbeling van het aantal advertenties het aantal rijen van de query met een factor 4 toe!
Online was de query in phpmyadmin 15 seconden. Lokaal 9 seconden
Thnx! dat was de oplossingquote:Op zaterdag 4 maart 2006 06:44 schreef JeRa het volgende:
De geescapede newlines (\n) werken over het algemeen alleen als je ze in een string zet met dubbele quotes (aanhalingstekens) eromheen, dus "\n" of "blaat\nblaat". Heb je ze toevallig in single quoted strings gezet? ( '\n' )
Misschien dat het dan aan de SQL versie ligt? Of misschien aan de join met een andere tabel?quote:Op zaterdag 4 maart 2006 13:04 schreef Light het volgende:
[..]
Ik heb hier nog een tabel kunnen vinden met 2000+ rows, met items in verschillende groepen. En daar kan ik best per groep de laatste 3 items uithalen met jouw query, kost maximaal ongeveer 0.02 seconden (op mijn pc).
Ik heb maar een simpele amd64 3000+ met 1GB.quote:Op zaterdag 4 maart 2006 13:18 schreef Swetsenegger het volgende:
[..]
Misschien dat het dan aan de SQL versie ligt? Of misschien aan de join met een andere tabel?
Mijn PC is namelijk niet de traagste (AMD64 3200+, 1GB Kingston HyperX)
En zowel online, als lokaal als bij SuperRembo is hij rete traag
Is goedquote:Ik wil je wel een dump van de tabellen mailen.
Drom, dus ik begrijp niet waarom de query bij mij veel trager zou zijnquote:Op zaterdag 4 maart 2006 13:31 schreef Light het volgende:
[..]
Ik heb maar een simpele amd64 3000+ met 1GB.
komt zo een zippie aan. gewoon at fok punt en el?quote:Is goed
Da's wel de makkelijkstequote:Op zaterdag 4 maart 2006 13:33 schreef Swetsenegger het volgende:
komt zo een zippie aan. gewoon at fok punt en el?
Je hebt mail terugquote:Op zaterdag 4 maart 2006 13:33 schreef Swetsenegger het volgende:
-edit- hij was nu sneller dan gisteren (misschien draaide mijn virusscanner ofzo) maar nog steeds goed voor bijna 4 seconden.
0.4 seconden!quote:Op zaterdag 4 maart 2006 14:19 schreef Light het volgende:
[..]
Je hebt mail terugEn het kan nog sneller
1 |
Je maakt een index, die noem je genre, en die gebruikt 2 velden, namelijk genre en ad_id.quote:Op zaterdag 4 maart 2006 14:28 schreef Swetsenegger het volgende:
[..]
0.4 seconden!
[ code verwijderd ]
Dit begrijp ik niet. Je zet een index op genre, maar die gebruikt twee velden ofzo?
1 |
Ah ok, het is een naampje.quote:Op zaterdag 4 maart 2006 14:30 schreef Light het volgende:
[..]
Je maakt een index, die noem je genre, en die gebruikt 2 velden, namelijk genre en ad_id.
Oh tof, die kende ik nietquote:Op zaterdag 4 maart 2006 12:14 schreef Swetsenegger het volgende:
[..]
Speciaal voor Tijn trouwens, kon je deze al?:
http://www.apple.com/downloads/macosx/unix_open_source/mamp.html
Ik ga denk ik ook maar zoeken naar een xserve
Alleen kom ik nergens een betaalbare xserve tegen.quote:Op zaterdag 4 maart 2006 20:25 schreef Tijn het volgende:
[..]
Oh tof, die kende ik nietMaar ik had PHP en MySQL al zelf draaiende gekregen op m'n Mac, dus op zich heb je het ook niet echt nodig. PHP stond er zo op en MySQL was met de bijgeleverde handleiding ook wel te doen
Sowieso bestaat er ook een server-versie van Mac OS X waar dit trouwens volgens mij al allemaal standaard in zit. Dat is ook het standaard OS van een XServe, dus dat heb je echt binnen 5 seconden werkend.
1 2 3 4 5 6 7 8 9 | function like_esc($string) { $string = mysql_real_escape_string($string); $string = str_replace('%', '\%', $string); $string = str_replace('_', '\_', $string); return $string; } ?> |
1) Wat geeft hij dan wél terug?quote:Op zondag 5 maart 2006 22:47 schreef Swetsenegger het volgende:
Hmz, $search=like_esc($_POST['search']); geeft bij %zoek% niet \%zoek\% terug zoals ik verwacht?
Niet gestripslashed, macig quotes staat aanquote:Op zondag 5 maart 2006 22:50 schreef JeRa het volgende:
[..]
1) Wat geeft hij dan wél terug?
2) Heb je vantevoren alles gestripslashes()'ed indien magic_quotes_gpc aan staat?
Inderdaad, ik weet verder ook niet waarom hij niet voor je werktquote:Op zondag 5 maart 2006 23:05 schreef Swetsenegger het volgende:
[..]
Niet gestripslashed, macig quotes staat aan
Maar goed, dan verwacht ik nog steeds dat ik wel een geescaped % terug krijgt toch? of wordt die OOK geslashed door magic quotes?
1 2 3 4 5 6 7 8 9 10 11 12 | require('../connect.php'); function like_esc($string) { $string = mysql_real_escape_string($string); $string = str_replace('%', '\%', $string); $string = str_replace('_', '\_', $string); return $string; } ?> |
1 2 3 4 5 | if($_SERVER['REQUEST_METHOD']=='POST'){ $search=like_esc($_POST['search']); $query="SELECT whatever FROM tabel WHERE iets LIKE'%".$search."%' || iets_anders LIKE'%".$search."%' || compleet_anders LIKE'%".$search."%' ORDER BY d DESC"; ?> |
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |