abonnement Unibet Coolblue Bitvavo
pi_35607051
Je hebt idd geen quotes om je value wat ik al zei... Er staan wel quotes,maar die sluiten je string af.

Die eerste van the_disheaver is trouwens fout, je kunt \n\r niet printen als een newline met single quotes, daar heb je double quotes voor nodig. Probeer het maar eens.

Dus die 2e van the_disheaver, of :
1echo "<td><input name='menunaam' type='text' value='". mysql_result($result,$i,'menunaam')."' /></td>\r\n";
pi_35607068
quote:
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)
dat werkt ja dankje!!
pi_35608381
Et laatste wat ik vraag... is het moeilijk een richt text edit box in mijn code te stoppen tussen de al bestaande text boxes?
pi_35612521
No offence Knucklezz, maar leer eerst eens de basis van html en php voor je vragen gaat stellen over elke regel code die je schrijft. Wat je hierboven noemt heeft ook echt 0,0 met php te maken.
pi_35614715
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:
1C:/php

php.ini staat in de WINDOWS map op de C:/schijf en daar zijn de volgende dingen gewijzigd:
1
2
extension_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
pi_35614736
preg_expr vraagje

wat kan ik gebruiken voor elk teken, inclusief nieuwe regels?
.* accepteert elk teken, behalve newlines.
Ik heb nu dit, werkt wel, maar kan het korter? [\d\s\w\W\n]*

En mijn preg_expr werkt niet.

Ik wil van een html pagina alleen hetgene binnen de
1
2
3
<div id="MCTable">
{elks teken incl newline}
</div>

Ik heb de regexp
1$table = preg_replace('#[\d\s\w\W\n]*(<div id="MCTable">[\d\s\w\W\n]*</div>)[\d\s\w\W\n]*#','$1' , $page);

Hij pakt meer dan hij zou moeten.
Ergens in het midden van de output ($table) staat:
1
2
3
    </div>
    
    <div id="MCaddtion">

Alleen de </div> zou er nog in moeten, alles eronder niet...

Waar zit mijn fout?

edit: opgelost door als einde niet naar </div> te zoeken, maar een tag boven de </div> tag. Doet het goed, maar geen echte oplossing.

[ Bericht 8% gewijzigd door the_disheaver op 01-03-2006 18:46:37 ]
pi_35615449
Regular expressions hebben ook modifiers:
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.
Dus /ene regel.*volgende regel/s werkt over meerdere regels.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
pi_35618490
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?
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
Kan niemand mij helpen?
pi_35618921
quote:
Op woensdag 1 maart 2006 20:08 schreef user931989 het volgende:
Kan niemand mij helpen?
file_get_contents
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
pi_35619613
quote:
Op woensdag 1 maart 2006 20:19 schreef SuperRembo het volgende:

[..]

file_get_contents
Bedankt, het is gelukt.
  donderdag 2 maart 2006 @ 02:26:43 #211
12221 Tijn
Powered by MS Paint
pi_35631835
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?
pi_35633236
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?
helemaal afhankelijk van wat je doet...
als je allerlei moeilijke bewerkingen doet en 20 query's opent zal het script er langer over doen wannneer je alleen 1 query uitvoert
pi_35642446
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?
  FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 15:54:33 #214
1972 Swetsenegger
Egocentrische Narcist
pi_35644895
Aangezien ik opzoek ben naar een design, wil ik een design request topic openen. Het is niet de bedoeling dat daar hele website designs aangevraagd worden, maar bv een logootje of een button.

Maar...zoals ik maar matig kan designen, zullen er best designers zijn welke matig kunnen PHP'en. Dus denk ik erover om ook een centraal script request topic te openen. Is daar draagvlak voor onder de PHP'ers?
pi_35648013
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?
Nee.
pi_35648097
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?
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.
  donderdag 2 maart 2006 @ 17:29:17 #217
12221 Tijn
Powered by MS Paint
pi_35648631
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.
pi_35648785
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.
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...

Edit: Spuit 11
  donderdag 2 maart 2006 @ 17:34:37 #219
12221 Tijn
Powered by MS Paint
pi_35648828
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...
Nee. PHP draait op de server.
pi_35648879
Sorry Tijn ik zal me er niet meer mee bemoeien

Mijn vraag nogmaals:
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:
1C:/php


php.ini staat in de WINDOWS map op de C:/schijf en daar zijn de volgende dingen gewijzigd:
1
2
extension_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
Foutmelding die ik dus krijg is:
1Fatal error: Call to undefined function mysql_connect() in C:\Program Files\Apache Group\Apache2\htdocs\Forum\Do_addtopic.php on line 10


pi_35649555
@DaFan

Don't slap me with a trout, maar heb je de Apache webserver opnieuw gestart?
pi_35649744
quote:
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?
15x ongeveer
  FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 18:39:56 #223
1972 Swetsenegger
Egocentrische Narcist
pi_35651045
quote:
Op donderdag 2 maart 2006 18:02 schreef DaFan het volgende:

[..]

15x ongeveer
Waarom download je geen compleet pakket zoals bijvoorbeeld appserv? Dan hoef je niets te configureren. Installeren en draaien maar
pi_35651202
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
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?
  FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 18:44:15 #225
1972 Swetsenegger
Egocentrische Narcist
pi_35651230
quote:
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?
Ja
pi_35651263
Meesterlijk, vanavond eens proberen
  FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:01:35 #227
1972 Swetsenegger
Egocentrische Narcist
pi_35656214
Ik heb de volgende tabellen, waarbij cursieve kolommen FK's zijn (duh).

produkten:
  • product_id
  • article_code
  • name
  • etc

    users
  • user_id
  • name
  • address
  • etc

    orders
  • order_id
  • user_id
  • etc

    order_content
  • content_id
  • order_id
  • product_id
  • etc

    Meest gebruikte queries zijn niet zo spannend:
    1
    2
    3
    4
    5
    6
    <?php
    $query
    ="SELECT *
                   FROM produkten
                   WHERE product_menu="
    .$_GET['id']."  
                   ORDER BY first_price ASC, product_id DESC"
    ;
    ?>


    Immers ga je de tabellen pas aan elkaar koppelen na een bestelling, daarbij krijg je queries zoals deze:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    <?php
    $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']."'";
    ?>



    Eerste vraag:
    Hebben indices in deze situatie zin? De meeste queries zijn redelijk straight forward, alleen bij bestellingen wat gecompliceerder, maar die komen ook maar mondjesmaat voor.

    Tweede vraag:
    Laten we gemakshalve even aannemen dat indices relevant zijn, van welke kolommen moet ik dan indices maken om performance te winnen?

    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?
  •   donderdag 2 maart 2006 @ 21:02:23 #228
    51748 H4ze
    wait...what?
    pi_35656247
    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....
    *BURP*
      FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:03:44 #229
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35656306
    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....
    php.ini?
      donderdag 2 maart 2006 @ 21:08:21 #230
    51748 H4ze
    wait...what?
    pi_35656471
    quote:
    Op donderdag 2 maart 2006 21:03 schreef Swetsenegger het volgende:

    [..]

    php.ini?
    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?
    *BURP*
      FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:11:09 #231
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35656570
    quote:
    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?
    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?
      donderdag 2 maart 2006 @ 21:12:59 #232
    51748 H4ze
    wait...what?
    pi_35656649
    quote:
    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?
    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....
    *BURP*
      FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:16:39 #233
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35656781
    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....
    en als je my.cnf file gewoon opent?
    pi_35656843
    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
    pi_35656852
    Fuck it, morgen weer een dag.
      FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:20:18 #236
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35656922
    quote:
    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
    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.php

    Meer valt er niet te configureren.
    Je hebt natuurlijk WEL eerste je voorgaande sql en php config gedelete.

    -edit- en wat ga je uberhaupt in MySQL command doen? Ga naar localhost/phpmyadmin.
    -edit2- Ow wacht, je moet een user aanmaken enzo http://www.phpfreakz.nl/artikelen.php?aid=62
    -edit3- Hoewel die standaard op root zonder password staat, en phpmyadmin daarmee moet kunnen verbinden.

    [ Bericht 5% gewijzigd door Swetsenegger op 02-03-2006 21:42:26 ]
      donderdag 2 maart 2006 @ 21:20:23 #237
    51748 H4ze
    wait...what?
    pi_35656926
    Ja ik was dus extreem scheef, kon die cnf file eerst niet vinden Krijg je van al de godganze dag zitten programmeren is nu opgelost

    Thnx iig
    *BURP*
    pi_35657513
    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?
    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.
    Wil iedereen die in telekinese gelooft nu mijn hand op steken?
    | Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
      FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:41:43 #239
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35657733
    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.
    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?

    Ik las namelijk op mysql.org dat het in sommige gevallen trager kan worden door indices.
    pi_35658279
    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?
    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:
    Ik las namelijk op mysql.org dat het in sommige gevallen trager kan worden door indices.
    In álle gevallen worden INSERTs trager door indices, en als het goed is kan MySQL zelf prima bepalen of het een index gebruikt of niet dus wat dat betreft zal het niet trager worden.
      FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 22:05:08 #241
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35658699
    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.
    Nee ok, alleen op kolommen waarop je selecteert of sorteert is een betere benaming.
    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 niet dus wat dat betreft zal het niet trager worden.
    Van mysql.org:
    If you need to access most of the rows, it is faster to read sequentially, because this minimizes disk seeks.

    Maar ja, in bovenstaand voorbeeld heb ik regelmatig ALLE product rows nodig. Zijn indexes dan aan te raden of niet?
    pi_35658935
    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
    MySQL staat nou niet echt goed bekend om z'n query optimalisatie kwaliteiten.
    Wil iedereen die in telekinese gelooft nu mijn hand op steken?
    | Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
    pi_35661362
    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?
    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:10 schreef SuperRembo het volgende:

    [..]

    MySQL staat nou niet echt goed bekend om z'n query optimalisatie kwaliteiten.
    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
      FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 08:57:08 #244
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35668673
    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
    First price heb ik inderdaad nu geindexeerd.
    Ik doelde ook op de foreign keys in de andere tabellen. DIe worden mondjes maat in joins gebruikt. Maar in mijn beleving zijn joins zware queries, dus wil ik het maar optimaliseren

    Bedankt weer voor de uitleg
      FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 11:04:18 #245
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35671495
    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?
    pi_35671593
    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?
    Laat eens zien?
      FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 11:13:37 #247
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35671744
    quote:
    Op vrijdag 3 maart 2006 11:08 schreef Scorpie het volgende:

    [..]

    Laat eens zien?
    De Query?

    1
    2
    3
    4
    5
    6
    7
    SELECT g.genre, g.genre_id, a.title, a.ad_id, a.image, a.price
    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


    -edit-
    indices op a.ad_id (PK), a.genre, g.genre_id (PK)
    pi_35671770
    quote:
    Op vrijdag 3 maart 2006 11:13 schreef Swetsenegger het volgende:

    [..]

    De Query?
    Wat anders?
    pi_35678562
    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.
    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?
    pi_35679254
    Hm ik zie zo 1,2,3 niet in waarom hij zo lang moet laden...heel apart. Hoeveel data bevatten de tabellen?
      FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 14:49:15 #251
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35679267
    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?
    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
      FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 14:49:58 #252
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35679291
    quote:
    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?
    ongeveer 2000 records in de ad table, 19 in de genre tabel en een stuk of 100 in de user tabel. ALlemaal niet erg spannend
    pi_35680110
    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
    Om voor testing purposes de query cache eventjes te omzeilen zou je SQL_NO_CACHE kunnen gebruiken, zie deze pagina.
    pi_35681112
    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)
    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:

    1GROUP BY g.genre, g.genre_id, a.title, a.ad_id, a.image, a.price


    Eventueel zou je alleen de PK's op kunnen nemen. Dan zijn de resultaten voorspelbaar maar misschien is het ietsje sneller

    1GROUP BY g.genre_id, a.ad_id
    Wil iedereen die in telekinese gelooft nu mijn hand op steken?
    | Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
      FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 16:27:40 #255
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35683202
    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 ]
    De aggregate functie is... het optel gebeuren?

    Inderdaad gaf hij af en toe onvoorspelbare resultaten met a.title in de GROUP BY, met a.ad_id lijkt dat verholpen Maar als ik de query een beetje volg lijkt hij me niet ZO traag toch? 15 seconden vind ik wel overdreven lang.
    pi_35685211
    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.
    Wil iedereen die in telekinese gelooft nu mijn hand op steken?
    | Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
    pi_35686454
    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.
      vrijdag 3 maart 2006 @ 18:44:01 #258
    51748 H4ze
    wait...what?
    pi_35687516
    Als ik via de post-method van een form iets meegeef, dan hoor ik die variabele op de 'volgende' pagina toch direct uitlezen met $variabele? Ik kan me herinneren dat ik dit altijd deed, maar nu ik de boel lokaal aan het maken ben, werkt dat niet. Ik moet dan de meegegeven variabele eerst uitlezen:

    $variabele = $_POST['bla'];

    En ik kan dus niet direct $bla gebruiken...Is het iets in de php.ini wat ik moet veranderen?
    *BURP*
    pi_35687556
    Ja. Maar je kan beter altijd $_POST en $_GET gebruiken. Vooral met POST, anders kunnen mensen iets in de URL veranderen en dan wordt dat gewoon geaccepteerd.

    register_globals
      vrijdag 3 maart 2006 @ 18:46:51 #260
    69357 R-Mon
    jong en dynamisch
    pi_35687584
    En anders extract.
    &lt;tsjsieb&gt; maarja, jij bent ook gewoon cool R-Mon :p
      FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 19:15:50 #261
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35688302
    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.
    Hier begrijp ik niets van.
    Ik zie de eerste rij in de tabel, die heeft genre id 1.
    Dan begint hij weer van bovenaf aan, alles negerend totdat hij er weer 1 tegenkomt met genre id 1. En weer bovenaan, tot hij een derde heeft gevonden met genre id 1.
    En zo voor alle genre's welke beschikbaar zijn in de genre tabel. Zeg ik het zo correct?

    Dan loopt hij toch door maximaal 19(genres)*3(max resultaten per genre)*2000(advertenties)= 114.000 rijen?

    Maar is er sowieso een manier om dit effectiever te doen?
    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.
    Dat dacht ik ook.
      FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 19:28:53 #262
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35688628
    Hmz, de hele database geexporteerd en lokaal geimporteerd.
    de query duurt ruim 9 seconden

    -edit-
    Een simpel

    1
    2
    3
    4
    5
    SELECT title, ad_id, image, price 
    FROM ad 
    WHERE genre=1 
    ORDER BY ad_id 
    DESC LIMIT 3

    duurt 0.0004 seconden.
    Snel rekensommetje leert dat

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    <?php
    $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
         
    }
    }
    ?>

    19*0.0004=0.0076 seconden duurt. Daar zal nog wel wat overhead vanaf vallen, maar ik denk dat het toch minimaal een factor 100 sneller is.

    Het gadverdamme ik haat een frontpage waarop 20 queries gedraaid worden. Ik vond SuperRembo's oplossing juist zo'n geile query

    -edit 2-
    Subqueries worden pas vanaf MySQL 5 ondersteunt toch?

    [ Bericht 49% gewijzigd door Swetsenegger op 03-03-2006 20:20:26 ]
    pi_35691840
    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
    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.
    Wil iedereen die in telekinese gelooft nu mijn hand op steken?
    | Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
      FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 21:22:14 #264
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35691949
    quote:
    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.
    Maar hij zag er wel heel cool uit en LIJKT veel sneller dan 20 queries

    Verrassend trouwens dat MSSQL zoveel sneller is. Toevallig heb ik van de week een intranet applicatie van MySQL naar MSSQL gemigreerd.
    pi_35692241
    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)
    En wat geeft de EXPLAIN van die query? Dat levert meestal wel info waarmee je kunt kijken wat er lang duurt.
      FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 21:57:41 #266
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35692943
    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.
    Of ik begrijp dat explain gewoon niet, of ik doe wat fout.
    Anyway, dit komt eruit

    1
    2
    3
    4
    table      type      possible_keys      key      key_len      ref           rows      Extra
    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
      zaterdag 4 maart 2006 @ 02:48:18 #267
    51748 H4ze
    wait...what?
    pi_35701218
    In een bericht wat ik via de php mail() functie stuur, zitten newlines (dus \n ). Dit zou gewoon een enter moeten geven, maar in het mailtje geeft ie gewoon letterlijk \n weer. Hij pakt in normale pagina's \n ook niet, dus volgens mij werken die escape characters niet. Ik dacht dat dit lag aan magic_quotes_gpc. Deze stond bij mij op Off, maar als ik 'm aanzet werkt 't alsnog niet... Is er iets anders wat ik moet veranderen?
    *BURP*
    pi_35702593
    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' )
    pi_35704239
    quote:
    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 ]
    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.
      FOK!-Schrikkelbaas zaterdag 4 maart 2006 @ 11:04:02 #270
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35704562
    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.

    ad_id is de PK, die is toch al index?
    pi_35704785
    quote:
    Op zaterdag 4 maart 2006 11:04 schreef Swetsenegger het volgende:

    [..]


    ad_id is de PK, die is toch al index?
    Ja, ik bedoelde dan ook een index op meerdere kolommen, namelijk genre en ad_id.
      FOK!-Schrikkelbaas zaterdag 4 maart 2006 @ 11:32:18 #272
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35705194
    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.
    dus de index op genre zou het juist trager maken ipv sneller?
    pi_35705324
    quote:
    Op zaterdag 4 maart 2006 11:32 schreef Swetsenegger het volgende:

    [..]

    dus de index op genre zou het juist trager maken ipv sneller?
    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.
      FOK!-Schrikkelbaas zaterdag 4 maart 2006 @ 12:14:32 #274
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35706275
    quote:
    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.
    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.

    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
    pi_35707016
    quote:
    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.
    Als ik hier lokaal ga testen dan is die query nog best snel. Maar ik heb natuurlijk geeen 2000 rows in een ad tabel
      FOK!-Schrikkelbaas zaterdag 4 maart 2006 @ 12:50:57 #276
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35707306
    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
    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
    pi_35707723
    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
    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).
      zaterdag 4 maart 2006 @ 13:05:44 #278
    51748 H4ze
    wait...what?
    pi_35707754
    quote:
    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' )
    Thnx! dat was de oplossing
    *BURP*
      FOK!-Schrikkelbaas zaterdag 4 maart 2006 @ 13:18:43 #279
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35708182
    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).
    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

    Ik wil je wel een dump van de tabellen mailen.
    pi_35708599
    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
    Ik heb maar een simpele amd64 3000+ met 1GB.
    quote:
    Ik wil je wel een dump van de tabellen mailen.
    Is goed
      FOK!-Schrikkelbaas zaterdag 4 maart 2006 @ 13:33:56 #281
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35708674
    quote:
    Op zaterdag 4 maart 2006 13:31 schreef Light het volgende:

    [..]

    Ik heb maar een simpele amd64 3000+ met 1GB.
    Drom, dus ik begrijp niet waarom de query bij mij veel trager zou zijn
    quote:
    Is goed
    komt zo een zippie aan. gewoon at fok punt en el?

    -edit- hij was nu sneller dan gisteren (misschien draaide mijn virusscanner ofzo) maar nog steeds goed voor bijna 4 seconden.
    pi_35708756
    quote:
    Op zaterdag 4 maart 2006 13:33 schreef Swetsenegger het volgende:

    komt zo een zippie aan. gewoon at fok punt en el?
    Da's wel de makkelijkste
    pi_35709896
    quote:
    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.
    Je hebt mail terug En het kan nog sneller
      FOK!-Schrikkelbaas zaterdag 4 maart 2006 @ 14:28:52 #284
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35710132
    quote:
    Op zaterdag 4 maart 2006 14:19 schreef Light het volgende:

    [..]

    Je hebt mail terug En het kan nog sneller
    0.4 seconden!

    1ADD INDEX `genre` ( `genre` , `ad_id` )

    Dit begrijp ik niet. Je zet een index op genre, maar die gebruikt twee velden ofzo?
    pi_35710165
    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?
    Je maakt een index, die noem je genre, en die gebruikt 2 velden, namelijk genre en ad_id.
    pi_35710206
    Het is dus, om het compleet te houden:
    1ALTER TABLE `ad` DROP INDEX `genre` , ADD INDEX `genre` ( `genre` , `ad_id` ) 
      FOK!-Schrikkelbaas zaterdag 4 maart 2006 @ 19:10:35 #287
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35717681
    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.
    Ah ok, het is een naampje.
    Ik wist dus niet dat je 1 index op 2 velden kon zetten. Ik dacht dat je een kolom index kon maken.
    En waneer er twee kolommen gebruikt worden, maak je die kolommen bijde index.

    Maar het is dus verstandiger om dan 1 index te maken, met die 2 kolommen, vat ik het zo een beetje behoorlijk samen?
      zaterdag 4 maart 2006 @ 20:25:53 #288
    12221 Tijn
    Powered by MS Paint
    pi_35719490
    quote:
    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
    Oh tof, die kende ik niet Maar 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.
      FOK!-Schrikkelbaas zaterdag 4 maart 2006 @ 21:34:04 #289
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35721832
    quote:
    Op zaterdag 4 maart 2006 20:25 schreef Tijn het volgende:

    [..]

    Oh tof, die kende ik niet Maar 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.
    Alleen kom ik nergens een betaalbare xserve tegen.
    Dus toch maar verder knutselen aan mijn Sun UltraSparc
    pi_35748865
    Uit een tabel wil ik informatie halen, die ik wil presenteren op alfabet. Met pagina-navigatie.
    In mijn query zal dus iets moeten zitten dat alle records ophaalt beginnend met een a enz.

    Maar hoe ziet mijn query eruit?

    select * from tabel WHERE name=..... (Hier moet ie dan alles records gebinnende met a selecteren.

    Hoe flik ik 'm dat?
      zondag 5 maart 2006 @ 18:54:40 #291
    3677 SuperRembo
    Sinds 1998
    pi_35748990
    Dat kan met de LIKE operator.
    Wil iedereen die in telekinese gelooft nu mijn hand op steken?
    | Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
    pi_35752408
    quote:
    Op zondag 5 maart 2006 18:54 schreef SuperRembo het volgende:
    Dat kan met de LIKE operator.
    Held, you made my day!
      FOK!-Schrikkelbaas zondag 5 maart 2006 @ 22:13:44 #293
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35756377
    quote:
    Op zondag 5 maart 2006 20:41 schreef beerten het volgende:

    [..]

    Held, you made my day!
    vergeet de wildcards niet %

    pi_35756833
    And as a side note to that, LIKE-queries zijn hartstikke handig maar je moet oppassen met user input. Sowieso zul je mysql_real_escape_string() moeten gebruiken om de user input te escapen, maar je zult ook alle percent-tekens en underscores moeten escapen omdat die een speciale betekenis hebben bij LIKE. Een handige functie is deze:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    <?php
    function like_esc($string)
    {
        
    $string = mysql_real_escape_string($string);
        
    $string = str_replace('%', '\%', $string);
        
    $string = str_replace('_', '\_', $string);
        return
    $string;
    }
    ?>
      FOK!-Schrikkelbaas zondag 5 maart 2006 @ 22:47:27 #295
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35757919
    Hmz, $search=like_esc($_POST['search']); geeft bij %zoek% niet \%zoek\% terug zoals ik verwacht?
    pi_35758050
    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?
    1) Wat geeft hij dan wél terug?
    2) Heb je vantevoren alles gestripslashes()'ed indien magic_quotes_gpc aan staat?
      FOK!-Schrikkelbaas zondag 5 maart 2006 @ 23:05:43 #297
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35758668
    quote:
    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?
    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?
    pi_35758770
    quote:
    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?
    Inderdaad, ik weet verder ook niet waarom hij niet voor je werkt hier werkt exact dezelfde code wél, na het aanmaken van een MySQL connectie. Heb jij dat ook?
      FOK!-Schrikkelbaas zondag 5 maart 2006 @ 23:11:59 #299
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35758896
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    <?php
    require('../connect.php');


    function
    like_esc($string)
    {
        
    $string = mysql_real_escape_string($string);
        
    $string = str_replace('%', '\%', $string);
        
    $string = str_replace('_', '\_', $string);
        return
    $string;
    }
    ?>


    Ja

    en ik roep 'm zo aan

    1
    2
    3
    4
    5
    <?php
    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";
    ?>


    Maar goed, het kan ook niet missen eigenlijk want het is een str_replace. Ik bedoel... het is geen exotische code ofzo. Het enige wat ik kon bedenken was dat ik de functie verkeerd aanriep ofzo
      zondag 5 maart 2006 @ 23:34:37 #300
    3677 SuperRembo
    Sinds 1998
    pi_35759635
    Maar wat staat er nou in $search (of in $query) ?
    Wil iedereen die in telekinese gelooft nu mijn hand op steken?
    | Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
    abonnement Unibet Coolblue Bitvavo
    Forum Opties
    Forumhop:
    Hop naar:
    (afkorting, bv 'KLB')