[MySQL|PHP] Hoe tabelveld te specificeren in IF statement

[mauricedb]

Ik heb een lijst met voetbalwedstrijden waar onder andere bij elke wedstrijd de uitslag staat. Nu wil ik deze uitslagen een kleurtje geven door middel van het IF statement. In de tabel staat naast alle wedstrijd info ook een optie (uitslaginletters) om te zeggen of de wedstrijd gewonnen, gelijk of verloren is. Hiermee wil ik de uitslagen een kleurtje gaan geven. Ik heb al de hele middag zitten zoeken op Google, maar ik kom er maar niet uit hoe ik de vergelijking moet doen, dus hoe ik het veld "uitslaginletters" ophaal om te kijken of deze matched met Gewonnen, Gelijk of Verloren. Nu heb ik het volgende:

SQL:

if('uitslaginletters' == 'Gewonnen')
    {
        Print "<td style='color:#009900;'>";
    }
elseif('uitslaginletters' == 'Gelijk')
    {
        Print "<td style='color:#e28800;'>";
    }
else
    {
        Print "<td style='color:#ff0000;'>";
    }

Deze code zorgt ervoor dat de laatste kleur, ff0000, getoond wordt bij alle uitslagen, omdat die natuurlijk niet de juiste vergelijking maakt.
Iemand die mij een duw in de goede richting kan geven?

PS. ik zat al te kijken om bijv $uitslaginletters = uitslaginletters te doen, maar dan kom ik eigenlijk weer bij dezelfde vraag terug, hoe zeg ik dat hij dat tabelveld moet pakken.

[ Voor 11% gewijzigd door mauricedb op 07-01-2012 19:56 ]

[Voutloos]

Je vergelijkt nu steeds een string met een andere string, terwijl je een variabele met een string wilt vergelijken. Kan wel de oplossing verklappen, maar je mist nu dusdanig basic kennis dat je beter het 1e hoofdstuk van een PHP boek of tutorial nogmaals door kan nemen.

Overigens nog een tip voor de html: Verdiep je eens in css. Uiteindelijk zal je beter een bepaalde class gebruiken en die middels css een stijl geven. Je zou zelfs letterlijk je tabelveld als class kunnen neerzetten en helemaal geen if statements meer nodig hoeven hebben.

[Firesphere]

Behalve dat je vraag incomplete informatie geeft... Wat Voutloos fautlooz aangeeft... je vergelijkt 2 strings... da wil nie!
'uitslaginletters' zal nooit van z'n leven 'Gewonnen' worden... Het is een string.

[mauricedb]

Dat snap ik, daarom ook mijn vraag, hoe krijg ik de variabele daar. Trouwens goed idee Voutloos over het tabelveld als class gebruiken, was ik nog niet opgekomen .

[Firesphere]

waar stel je in dat er gewonnen/verloren/gelijkgespeeld is?

[mauricedb]

Ik heb een tabel ''wedstrijden'' met o.a. de velden uitslagincijfers en uitslaginletters. Bij uitslaginletters kan er alleen gekozen worden voor het winnen, gelijk spelen of verliezen, of bedoel je dat niet?

[Firesphere]

code:

if($score['home'] < $score['away']){
    $class = 'win';
}
elseif($score['home'] == $score['away']){
   $class = 'equal';
}
else{
   $class = 'loss';
}

En dan gewoon je echo doen:
echo '<td class=" '.$class.' "></td>

Het spijt me, maar verder dan dat wil ik je niet helpen. Lees echt, zoals Voutloos zegt nog eens in op PHP. Het is een heel simpel scripting systeem. Niet eens een echte taal.

Lees je eens in op variabelen, comparison en CSS. Tof dat je probeert hoor Maar je fouten lijken (so far) echt wel zo basic, dat het weinig zin heeft. Sorry.

[mauricedb]

Ah, ik ben er al uit:

SQL:

if($info['uitslaginletters'] == 'Gewonnen')
    {
        Print "<td style='color:#009900;'>";
    }
elseif($info['uitslaginletters'] == 'Gelijk')
    {
        Print "<td style='color:#e28800;'>";
    }
else
    {
        Print "<td style='color:#ff0000;'>";
    }

Alsnog bedankt voor het reageren, ik ga zeker even kijken naar die ene optie van Voutloos.
Ik zat telkens met .$info te kloten, maar die punt moest dus blijkbaar weg.

[ Voor 9% gewijzigd door mauricedb op 07-01-2012 20:23 ]

[Firesphere]

mauricedb schreef op zaterdag 07 januari 2012 @ 20:22:
Ah, ik ben er al uit:

SQL:

if($info['uitslaginletters'] == 'Gewonnen')
    {
        Print "<td style='color:#009900;'>";
    }
elseif($info['uitslaginletters'] == 'Gelijk')
    {
        Print "<td style='color:#e28800;'>";
    }
else
    {
        Print "<td style='color:#ff0000;'>";
    }

Alsnog bedankt voor het reageren, ik ga zeker even kijken naar die ene optie van Voutloos.
Ik zat telkens met .$info te kloten, maar die punt moest dus blijkbaar weg.

Ga alsjeblieft met html/css class werken ipv de style direct toepassen. Er is maar 1 reden om styles inline te gebruiken. En dat is als je dynamisch breedte's etc. wil aanpassen. Omdat voor elke pixel een breedte definieren in CSS een beetje extreem veel werk is.

Er zijn een paar varianten te noemen, maar 3 statische kleuren? Dat is CSS-werk.

Verder is het vergelijken van strings een tricky zaak als je niet 100% zeker bent van de string.

beter is in ieder geval de strings sowieso lowercase te checken in PHP, dan is je hoofdlettergevoeligheid er al uit.
Je maakt het jezelf erg moeilijk voor iets simpels.

Waarom doe je geen check op punten? 3-1-0 punten voor win-equal-loss, weel statischer en gemakkelijker te vergelijken.
En je hebt de $info al, daar doe je eerder al iets mee lijkt me. Zorg er voor dat alle definitieve gegevens VOORAF bekend zijn, en ga dan pas dingen naar de HTML pushen, heb je alles onder 1 dak. Als ik nu zo zie, ga jij een aantal keer dingen vergelijken die je eigenlijk al eerder hebt gedaan.
if(statement = true){
doe hier alles;
}
$result = bouw je resultaat-html hier;
echo $result

Zo verschrikkelijk veel makkelijker!


p.s.
Je hebt mij en een aantal kennissen van me wel aan het lachen/huilen gebracht met je originele code. Sorry, maar ik moest'm gewoon ff delen met de anderen. (Naamloos, uiteraard )

p.p.s.
[code=sql] != [code=php]

[ Voor 36% gewijzigd door Firesphere op 07-01-2012 20:51 . Reden: Ben de beroerdste niet. ]

[mauricedb]

Ik weet natuurlijk niet hoe jullie ''werken'', maar ik wil het eerst werkend hebben voordat ik het ''mooi'' ga maken (vooral bij dingen als deze waarvan ik niet, precies, weet hoe het moet). Daarnaast weet ik wel het een en ander af van html/css/php/mysql etc, maar ik leer meer door dingen te doen, dan door (bijv) boeken te lezen, daarom zal ik bepaalde (basis) dingen niet (direct) weten.

Mooi trouwens dat jij (Firesphere) en ''je aantal kennissen'' hebben kunnen lachen om mijn code in de TS, waarbij ik in zekere zin uitleg dat deze code sowieso niet (goed) werkt en waar ik zeg dat ik wel denk te weten hoe het moet, maar niet weet hoe het te implementeren (daarom vraag ik het aan jullie), sorry daarvoor, ik zal het nooit meer doen!

[RobIII]

Firesphere schreef op zaterdag 07 januari 2012 @ 20:27:
p.s.
Je hebt mij en een aantal kennissen van me wel aan het lachen/huilen gebracht met je originele code. Sorry, maar ik moest'm gewoon ff delen met de anderen. (Naamloos, uiteraard )

Fijn dat je zo met je maten hebt kunnen lachen om andermans code; maar we zijn allemaal ooit ergens begonnen. Jij ook. Hou dit dan voortaan ook gewoon voor je; het hier melden is totaal nutteloos en niet erg sportief, vind je ook niet?

Firesphere schreef op zaterdag 07 januari 2012 @ 20:27:
beter is in ieder geval de strings sowieso lowercase te checken in PHP, dan is je hoofdlettergevoeligheid er al uit.

Zal ik jou ook meteen eens bijscholen dan: strings naar upper/lowercase converteren en dan comparen is nog altijd slechter dan een case-insensitive compare doen. Waarom? Daarom, daarom, daarom, hierom. Zo zie je maar; er is altijd wel iemand die 't beter weet
(Of PHP's case-insensitive string compare er daadwerkelijk goed mee omgaat weet ik overigens niet; je advies (lowercase versies comparen) gaat gewoon niet altijd op).

[edit]
Het werkt iig niet in PHP met strcasecmp:

PHP:

runtests('nl_NL');
runtests('tr_TR');

function runtests($locale) {
  echo 'Running tests with locale '.$locale.'<br>';
  setlocale(LC_ALL, $locale);
  dotest(strtolower('HOI') === 'hoi');
  dotest(strtoupper('hoi') === 'HOI');
  dotest(strcasecmp('HOI','hoi') === 0);
}

function dotest($e) {
  echo ($e ? 'equal' : 'not equal') . '<br>';
}

Running tests with locale nl_NL
equal
equal
equal
Running tests with locale tr_TR
not equal
not equal
not equal

Die laatste regel had dus, had strcasecmp z'n werk goed gedaan, 'equal' moeten zijn.
Maar ik kan niet echt zeggen dat 't me verbaast tbh

[ Voor 34% gewijzigd door RobIII op 07-01-2012 21:31 ]

[Firesphere]

mauricedb schreef op zaterdag 07 januari 2012 @ 21:00:
Mooi trouwens dat jij (Firesphere) en ''je aantal kennissen'' hebben kunnen lachen om mijn code in de TS, waarbij ik in zekere zin uitleg dat deze code sowieso niet (goed) werkt en waar ik zeg dat ik wel denk te weten hoe het moet, maar niet weet hoe het te implementeren (daarom vraag ik het aan jullie), sorry daarvoor, ik zal het nooit meer doen!

Het ging me in dit geval om de directe string-to-string vergelijking. Ik vertel het je eerlijk, meer niet. Gewoon het moment zelf dat we er even om moesten lachen.

Ik heb er eerst een copy-paste van gemaakt, en daarna pas aan iemand anders laten zien (alleen de eerste IF, gewijzigd naar random strings), zonder naam, uiteraard, zoals ik al zei.
Sorry, we zitten hier nou eenmaal. Ik weet dat je zei dat het niet werkt, en daarom heb ik ook geprobeerd je verder te helpen.

Ja, natuurlijk heb ik ook vaak genoeg dergelijke fouten gemaakt. En je mag het best vragen hoor . Dat bedoel ik niet

Ik zit hier op dit moment met een paar coders, dus tja... dan gebeurt dat. Verder helemaal niets.

RobIII schreef op zaterdag 07 januari 2012 @ 21:10:
Zal ik jou ook meteen eens bijscholen dan: strings naar upper/lowercase converteren en dan comparen is nog altijd slechter dan een case-insensitive compare doen. Waarom? Daarom, daarom, daarom, hierom. Zo zie je maar; er is altijd wel iemand die 't beter weet

Die situatie ken ik ja. En die is goed te ondervangen als je iets weet van Turks (ja, nee, ik niet, heb er ook nog geen interactie mee gehad. Maar wel Duits, waar de ringeles wordt omgezet naar "iets", ook een probleem). In dit geval gaat het echter om een andere situatie.

Turks (en ook Syrisch, Arabisch, etc.) is altijd lastig en kan je geen lowercase compare uitvoeren. Klopt. Mijn antwoordt was ook direct gericht op het "algemene Latin" alfabet, niet de uitzonderingen die inderdaad grote problemen kunnen veroorzaken. Dit is bij mij bekend. Uiteraard. Dit is vergelijkbaar met wachtwoorden naar lcase zetten "ach, dan gaat't tenminste goed", is dezelfde fout.

In dit geval gaat het echter om een semi-statisch gegeven. En dan is lowering wel een gemaks-optie die een typo oplost.

[RobIII]

Firesphere schreef op zaterdag 07 januari 2012 @ 21:26:
Dit is vergelijkbaar met wachtwoorden naar lcase zetten "ach, dan gaat't tenminste goed", is dezelfde fout.

Dat zie ik even niet hoe dat 'tzelfde is...

Firesphere schreef op zaterdag 07 januari 2012 @ 21:26:
In dit geval gaat het echter om een semi-statisch gegeven. En dan is lowering wel een gemaks-optie die een typo oplost.

Waarom zou je gaan lower/upper-casen als je toch gewoon case-insensitive compare kunt gebruiken dan?

[ Voor 28% gewijzigd door RobIII op 07-01-2012 21:30 ]

[Firesphere]

RobIII schreef op zaterdag 07 januari 2012 @ 21:29:
[...]

Dat zie ik even niet hoe dat 'tzelfde is...

Omdat ik het wel eens heb zien gebeuren helaas. En dan niet op het niveau "jantje heeft een site"

RobIII schreef op zaterdag 07 januari 2012 @ 21:29:
[...]

Waarom zou je gaan lower/upper-casen als je toch gewoon case-insensitive compare kunt gebruiken dan?

Omdat het om een Latin string gaat in dit geval. En een typo (er staat ineens "gewonnen" ipv "Gewonnen"), dat probleem dan oplost.
Dat was alles van het advies.

Zodra je in UTF8 of een ISO standaard zit, levert dit inderdaad een probleem op.

Standaard gewoonte trouwens:

PHP:

if(strtolower($value) == strtolower('value')){
 do stuff;
}

Niet slechts 1 kant loweren.

Ik heb inderdaad geen ervaring met Arabische talen, behalve dat ik het alfabet ergens op een papiertje heb zwerven hier.
En laat me er ook zo ver mogelijk bij weg blijven.... ben al lang blij dat ik 3 talen redelijk vloeiend kan spreken!

[ Voor 13% gewijzigd door Firesphere op 07-01-2012 21:36 ]

[RobIII]

Firesphere schreef op zaterdag 07 januari 2012 @ 21:34:
Omdat ik het wel eens heb zien gebeuren helaas. En dan niet op het niveau "jantje heeft een site"

We gaan nu wel wat offtopic, maar dan ben ik toch eens benieuwd hoe die situatie was want het is gewoon niet vergelijkbaar. Ongeacht of je nou een hash of niet zou gebruiken (en dus plaintext zou opslaan); dan had 't met geen énkel wachtwoord gewerkt. Lowercase je dan compare je later met de ("incorrecte", maar wel zelfde uitkomst) van de lowercase en dus werkt 't wachtwoord gewoon. Gebruik je een hash (al dan niet van een vooraf lower/uppercased string) dan zal die hash ook ("incorrect" lower/uppercased) een tweede keer exact dezelfde uitkomst geven.

Firesphere schreef op zaterdag 07 januari 2012 @ 21:34:
Dat was alles van het advies.

Mijn opmerking (en posts erna) was juist dat je advies in ieder geval 1 edge case kent die mis gaat en dat 't (links, rechts, links én rechts) lower/uppercasen van strings nog altijd veel omslachtiger is dan gewoon meteen een case-insensitive stringcompare te gebruiken.

[Firesphere]

RobIII schreef op zaterdag 07 januari 2012 @ 21:47:
[...]

We gaan nu wel wat offtopic, maar dan ben ik toch eens benieuwd hoe die situatie was want het is gewoon niet vergelijkbaar. Ongeacht of je nou een hash of niet zou gebruiken (en dus plaintext zou opslaan); dan had 't met geen énkel wachtwoord gewerkt. Lowercase je dan compare je later met de ("incorrecte", maar wel zelfde uitkomst) van de lowercase en dus werkt 't wachtwoord gewoon. Gebruik je een hash (al dan niet van een vooraf lower/uppercased string) dan zal die hash ook ("incorrect" lower/uppercased) een tweede keer exact dezelfde uitkomst geven.


[...]

Mijn opmerking (en posts erna) was juist dat je advies in ieder geval 1 edge case kent die mis gaat en dat 't (links, rechts, links én rechts) lower/uppercasen van strings nog altijd veel omslachtiger is dan gewoon meteen een case-insensitive stringcompare te gebruiken.

Gaat inderdaad heel ver offtopic, maar ik heb 3x gezien dat een wachtwoord stiekem lowercase werd gehasht (salten, wat is dat?), en dus op die manier gecheckt. that's all

Daarnaast vergelijk ik niet graag strings... ze zijn te gevoelig. Dus als't kan is een static integer een slimmer idee.

p.s.
Mijn reactie dat we er om konden lachen kwam inderdaad ietwat verkeerd over. Daarvoor mijn excuses. We zijn hier nu met 4 (zonet 5) personen. En ik heb het eerst expres compleet geanonimiseerd. En ik weet dat de anderen geen tweakers zijn trouwens.

[ Voor 5% gewijzigd door Firesphere op 07-01-2012 22:09 ]

[mauricedb]

Heb het nu mooi met classes gedaan, iedereen bedankt voor het reageren, wat mij betreft mag het topic dicht

[Ventieldopje]

Firesphere schreef op zaterdag 07 januari 2012 @ 22:07:
[...]

Gaat inderdaad heel ver offtopic, maar ik heb 3x gezien dat een wachtwoord stiekem lowercase werd gehasht (salten, wat is dat?), en dus op die manier gecheckt. that's all

Daarnaast vergelijk ik niet graag strings... ze zijn te gevoelig. Dus als't kan is een static integer een slimmer idee.

p.s.
Mijn reactie dat we er om konden lachen kwam inderdaad ietwat verkeerd over. Daarvoor mijn excuses. We zijn hier nu met 4 (zonet 5) personen. En ik heb het eerst expres compleet geanonimiseerd. En ik weet dat de anderen geen tweakers zijn trouwens.

Heb jij non-tweaker vrienden? Schaam je, iedereen zal zich bekeren tot het geloof dat Tweakers.net heet (*kuch* zweden anyone?)

Waarom zou je ook een wachtwoord lower-case hashen?

@mauricedb, Anyway, waarom heb je in de database eigenlijk een veld staan met "uitslaginletters". Als je de scores hebt kun je makkelijk in je code berekenen wie er gewonnen heeft, bovendien voorkom je dan fouten als je de scores aanpast en vergeet het "uitslaginletters" veld aan te passen

In 99% van de gevallen zet je in de database de informatie (feiten, concrete nummers en waarden) en ga in je in runtime dingen met die informatie doen zoals kijken of iemand gewonnen heeft of niet, kijken wie de beste was etc.

Ik raad aan een goed boek over PHP / MySQL te pakken van een bekende uitgever als O'Reilly of Wrox zoals: http://shop.oreilly.com/product/9780596515867.do of http://www.wrox.com/Wiley...productCd-0470413964.html

Vaak in de eerste paar hoofdstukken worden al dit soort dingen uitvoerig en duidelijk besproken, zelf leer ik ook door te doen maar wat ik persoonlijk erg fijn vind is een (al dan niet vaag) voorbeeld als ik iets niet weet hoe ik iets aan moet pakken, de kunst zit hem dan in het voorbeeld te snappen (in boeken wordt het vaak duidelijk uitgelegt) en er uit te halen en toe te passen op het gene wat jij wil doen!

echo() is sneller als print() btw

[mauricedb]

Thnx voor de tip van echo Meteen gewijzigd. Wat dat veld betreft, tja, zo leek mij het wel handig. De database is verder niet heel uitgebreid en het veld uitslagincijfers bestaat uit vijf tekens ("1 - 3"), dan lijkt het mij al wat lastiger (sowieso voor mij) om te doen wat jij zegt, dan wanneer je velden hebt als uitslagthuis en uitslaguit. Misschien had ik beter dat laatste kunnen doen, want dan kun inderdaad (makkelijker) doen wat jij zegt, maar dit is meer een probeersel voor mijn eigen site (waar ik nu dus weer het één en ander van geleerd heb) dan dat het echt iets professioneels moet worden.

[Firesphere]

mauricedb schreef op zondag 08 januari 2012 @ 18:02:
Thnx voor de tip van echo Meteen gewijzigd. Wat dat veld betreft, tja, zo leek mij het wel handig. De database is verder niet heel uitgebreid en het veld uitslagincijfers bestaat uit vijf tekens ("1 - 3"), dan lijkt het mij al wat lastiger (sowieso voor mij) om te doen wat jij zegt, dan wanneer je velden hebt als uitslagthuis en uitslaguit. Misschien had ik beter dat laatste kunnen doen, want dan kun inderdaad (makkelijker) doen wat jij zegt, maar dit is meer een probeersel voor mijn eigen site (waar ik nu dus weer het één en ander van geleerd heb) dan dat het echt iets professioneels moet worden.

Je uitslagveld is dus 1-3 (bijvoorbeeld).

Nu zie ik toch een paar problemen, wat als het 10 - 0 wordt? Da's 6 tekens

Betere oplossing is een HomeScore en AwayScore veld gebruiken. Die beide een int(2) geven, en je kan alles uit de vergelijking halen tussen home en away.

Verder, als je toch de tekst "1 - 3" hebt en het aanpassen je teveel moeite is omdat het er toch al staat:
explode je veld op '-', een trim er overheen, en je hebt een array van 2 integers die je net zo makkelijk kan vergelijken. Het tekstveld is daarmee in 1x overbodig geworden, omdat PHP het kan berekenen

[mauricedb]

Lol, nog helemaal niet bij stil gestaan dat het ook inderdaad 6 tekens kunnen zijn Zal wel komen omdat FC Twente (waar ik alleen de wedstrijden van bij hou), nooit met zulke hoger cijfers wint/verliest Maar zoals ik ook al zei, dit is meer een probeersel/hobby, dus probeer er eigenlijk alleen maar van te leren. Zal eens een keer kijken naar hetgeen wat je als laatst typt, dat je het veld splitst in meerdere velden/arrays, kijken of ik dat voor elkaar krijg .

[Firesphere]

mauricedb schreef op zondag 08 januari 2012 @ 18:23:
Lol, nog helemaal niet bij stil gestaan dat het ook inderdaad 6 tekens kunnen zijn Zal wel komen omdat FC Twente (waar ik alleen de wedstrijden van bij hou), nooit met zulke hoger cijfers wint/verliest Maar zoals ik ook al zei, dit is meer een probeersel/hobby, dus probeer er eigenlijk alleen maar van te leren. Zal eens een keer kijken naar hetgeen wat je als laatst typt, dat je het veld splitst in meerdere velden/arrays, kijken of ik dat voor elkaar krijg .

FC Twente

Anyway,
$val = explode('-', '1 - 3');
levert de volgende array op:
$val[0] = '1 ';
$val[1] = ' 3';

Als je daar een trim (spaties verwijderen) en een (int) statement bij gooit, heb je een array van 2 integers...

Hoe minder je opslaat en hoe meer je berekent, hoe beter, vind ik.

[ Voor 4% gewijzigd door Firesphere op 08-01-2012 18:29 ]

[mauricedb]

Is het dan in mijn geval zo (in ieder geval iets in die geest)?

$val = explode('-', '$info['uitslaginletters']');

En dat ik dan inderdaad $val[0] en [1] kan gebruiken om te vergelijken met de thuis en uit spelende ploeg?
Maar dan moet er dus gekeken worden welk getal hoger is en dat hij die dan de class gewonnen meegeeft en de ander automatisch verloren, of bij 1 - 1 natuurlijk gelijkspel.

[Firesphere]

Ja, afhankelijk van hoe je het invoert natuurlijk.

Let wel, 0 is altijd de linker value (thuisspelende ploeg) en 1 altijd de uitploeg (tenminste, als je consequent invoert )

maar met die simpele switch (if 0 <1, if 0 > 1, else), kun je alles vervolgens instellen. Zit je niet meer met teksten o.i.d. je hebt gewoon je variabelen.

Als je niet weet wat de output is, var_dump($variabele);exit; en je krijgt een dump van de genoemde variabele. Afhankelijk van je hosting, is dit een lelijke onleesbare array (bekijk dan de broncode), of een mooi gestylede dump, met dank aan xDebug.

[mauricedb]

Okee, alleen heb ik in mijn tabel enkel de club staan waar twente tegen moet, en een veld of twente thuis of uit speelt. Dan zou ik dus een stukje code moeten hebben die kijkt naar of het thuis of uit is, dan moet die kijken welke waarde (0 of 1) hoger is en vervolgens kan die dan de juiste class toevoegen.

Als ik het nu aan het rechte eind heb, is dit dan niet nog gecompliceerder dan wat ik nu heb (door te kijken naar het veld of er gewonnen, verloren of gelijk gespeeld is)? Daar komt wel bij dat ik dan 1 veld minder hoef in te vullen, maar ook dan (als ik het dus juist heb) moet de code gaan vergelijken met een stukje tekst van een veld.

[Firesphere]

mauricedb schreef op zondag 08 januari 2012 @ 19:08:
Okee, alleen heb ik in mijn tabel enkel de club staan waar twente tegen moet, en een veld of twente thuis of uit speelt. Dan zou ik dus een stukje code moeten hebben die kijkt naar of het thuis of uit is, dan moet die kijken welke waarde (0 of 1) hoger is en vervolgens kan die dan de juiste class toevoegen.

Als ik het nu aan het rechte eind heb, is dit dan niet nog gecompliceerder dan wat ik nu heb (door te kijken naar het veld of er gewonnen, verloren of gelijk gespeeld is)? Daar komt wel bij dat ik dan 1 veld minder hoef in te vullen, maar ook dan (als ik het dus juist heb) moet de code gaan vergelijken met een stukje tekst van een veld.

Qua PHP is het inderdaad iets complexer, maar qua functionaliteit veel preciezer. met harde integers kun je veel meer berekenen.
Qua snelheid is het ook veel beter. Hoe meer PHP berekent, hoe minder het hoeft te wachten op een database.

Je huidige situatie werkt wel, maar kan geoptimaliseerd worden door minder van je database afhankelijk te zijn. Dat is alles

[mauricedb]

Okee, ik vat 'm. Voor nu hou ik 'm zoals ik het nu heb, misschien dat ik het later eens ga proberen op jouw manier Bedankt voor je reacties.

[RobIII]

mauricedb schreef op zondag 08 januari 2012 @ 15:58:
Heb het nu mooi met classes gedaan, iedereen bedankt voor het reageren, wat mij betreft mag het topic dicht

Een slotje is niet nodig op een topic als je je oplossing hebt. Zie daarvoor ook onze faq betreffende topiceinde.

Ventieldopje schreef op zondag 08 januari 2012 @ 16:27:
echo() is sneller als print() btw

Utterly loze 'optimalisatie'. Als je hier al je 'winst' uit moet gaan halen heb je toch wel een héél serieus probleem.
Als je 't wil weten, 't scheelt volgens mijn metingen (maar dan op een eigen systeem) 0.000000004s. Dat betekent, op mijn systeem, dat je al ruim 13.000.000 print-statements in je code moet hebben staan in je code wil je 1 hele seconde winnen.

[ Voor 17% gewijzigd door RobIII op 08-01-2012 22:46 ]

[ValHallASW]

RobIII schreef op zaterdag 07 januari 2012 @ 21:10:
Die laatste regel had dus, had strcasecmp z'n werk goed gedaan, 'equal' moeten zijn.
Maar ik kan niet echt zeggen dat 't me verbaast tbh

Nee, strcasecmp doet z'n werk wél goed: in de Turkse locale zijn de I en de i namelijk niet dezelfde letter, dus is geeft een case-insensitive compare óók false.

Wat je zoekt is een collation-aware string compare, waarbij je een collation gebruikt waar de I en i wél hetzelfde zijn. De mysql-equivalenten zijn:

nl_NL: (er is geen 'dutch' locale, maar de standaard-sortering klopt met wat je in NL verwacht)

SQL:

select ('HOI' COLLATE utf8_unicode_ci) = ('hoi' COLLATE utf8_unicode_ci) as nl_NL;

levert: nl_NL = 1

terwijl
tr_TR:

SQL:

select ('HOI' COLLATE utf8_turkish_ci) = ('hoi' COLLATE utf8_turkish_ci) as tr_TR;

oplevert tr_TR = 0.

Het hangt ook nogal van de context af wat het correcte gedrag is. In het geval van Nederlandse tekst gebruik je de 'standaardvergelijking' waarbij I = i (case-insensitive) en ij=ij (dat zijn een digraph en twee losse tekens). In het geval van Turkse tekst is dat juist niet goed, omdat de i en de ı fundamenteel verschillende letters zijn.

overigens moet je in zowel PHP als python de locale aanpassen om de collation in te stellen. Dat heeft er dan weer mee te maken dat ze beiden gewoon de C strcmp gebruiken en de ontwikkelaars dáárvan hebben blijkbaar wél over dit soort dingen nagedacht. Je weet wel, LC_COLLATE.

[ Voor 10% gewijzigd door ValHallASW op 09-01-2012 00:25 ]

[RobIII]

I stand corrected Je hebt inderdaad gelijk en ik had een wat minder helder momentje

[ Voor 60% gewijzigd door RobIII op 09-01-2012 01:29 ]