[PHP/(My)SQL] voor dummies - Deel 72

quote:

Op woensdag 17 juni 2009 08:41 schreef Xcalibur het volgende:
je kan ook gewoon van $sql een array maken, en daar al je queries inzetten
Dan kan je met een count($sql) zien hoeveel queries je hebt gedraaid

ah dat is een optie die ik zeker ga overwegen .

maar dan maak ik voor elke query. als praktisch voorbeeld:
?

quote:

Op woensdag 17 juni 2009 09:12 schreef Scorpie het volgende:

[..]

Nou ja ik gebruik deze logger vooral om acties te loggen, dus zeg maar wanneer iemand inlogged, dan schrijf ik een regel weg met "Gebruiker A is ingelogged", dat soort dingen.

Je kan het ook wel gebruiken om errors van PHP te loggen, maar die worden standaard al gelogged.

ja , maar ik kom er niet achter hoe ik die kan veranderen. denk dat mijn config file niet meewerkt herstart ik xampp doet hij het nog niet.

wat ik doe :
ik open php5.ini C:\xampp\php\php5.ini
1: reg 353 error_log = "C:\xampp\htdocs\cablegunmaster v3.0\log_file.txt"
alleen hij wil hem niet zo hebben :p want hij logt nog steeds in de standaard locatie

het ging me voornamelijk om de php errors te loggen . desnoods tonen

[ Bericht 6% gewijzigd door cablegunmaster op 17-06-2009 09:42:56 ]

quote:

Op woensdag 17 juni 2009 09:42 schreef Scorpie het volgende:

[..]

Das ook wat anders dan deze loggerclass die ik gemaakt heb

zet eens voor de functie LOG_FILE = "c:\log.txt";

Kwam ik ook achter dit is voor nette foutmelding naar de user toe na een paar paginas door te lezen

heb het al gefixt stomme ; ervoor . lees er soms ook over heen kleine fouten waar ik op zit .
dit maar eens doorgeven aan m'n webhost dit bestandje ^^ , kan het zelf namelijk niet aanpassen .

stomme webhost

[ Bericht 26% gewijzigd door cablegunmaster op 17-06-2009 09:49:38 ]

Over het loggen van SQL queries gesproken.. Is er ook een manier om af te vangen wat er EXACT naar de database gestuurd word? Ik maak gebruik van PDO, en als ik mijn queries log staan de variabelen hier nog in.. iets als "SELECT * FROM tabel WHERE veld = :waarde". Bij debuggen heb ik daar soms niet zo gek veel aan..

quote:

Op woensdag 17 juni 2009 09:06 schreef cablegunmaster het volgende:

[..]

ah dat is een optie die ik zeker ga overwegen .

maar dan maak ik voor elke query. als praktisch voorbeeld:
[ code verwijderd ]

?

In principe wel ja. Het is alleen wel handig om je query een naam te geven
$sql['query_1'] = ''; dus

quote:

Op woensdag 17 juni 2009 09:55 schreef Intrepidity het volgende:
Over het loggen van SQL queries gesproken.. Is er ook een manier om af te vangen wat er EXACT naar de database gestuurd word? Ik maak gebruik van PDO, en als ik mijn queries log staan de variabelen hier nog in.. iets als "SELECT * FROM tabel WHERE veld = :waarde". Bij debuggen heb ik daar soms niet zo gek veel aan..

Ik heb zelf een functie die mysql_query() overkoepelt en wanneer ik mijn Boolean $Log aan zet, de queries die uitgevoerd worden in String-vorm naar een log bestand schrijven. Want de query die je in functie mysql_query() gebruikt is niet meer dan dat, een String.

quote:

Op woensdag 17 juni 2009 13:01 schreef Tuvai.net het volgende:

[..]

Ik heb zelf een functie die mysql_query() overkoepelt en wanneer ik mijn Boolean $Log aan zet, de queries die uitgevoerd worden in String-vorm naar een log bestand schrijven. Want de query die je in functie mysql_query() gebruikt is niet meer dan dat, een String.

Ja, maar ik wil wel gebruik blijven maken van PDO in combinatie met prepared statements, dus da ga nie werken nie.

quote:

Op woensdag 17 juni 2009 13:01 schreef Tuvai.net het volgende:

[..]

Ik heb zelf een functie die mysql_query() overkoepelt en wanneer ik mijn Boolean $Log aan zet, de queries die uitgevoerd worden in String-vorm naar een log bestand schrijven. Want de query die je in functie mysql_query() gebruikt is niet meer dan dat, een String.

Zoiets gelijks hebben wij hier ook inderdaad.
Daarnaast wordt per classe eigenlijk de log-classe aangeroepen, zodat we allerlei logs gescheiden van elkaar in ieders een aparte folder bewaren en wordt er 1 log file per dag gecreëerd.

Vraagje:

Ik heb de volgende functie om te berekenen hoeveel afstand er tussen 2 coordinaten zit:



Echter, nu heb ik een database met +300.000 records.
Ik wil dat de gebruiker kan zeggen: ik wil binnen een straal van xx KM de resultaten zien.
Dat kunnen ze doen door een postcode in te vullen, waar ik een ander script voor heb om de coordinaten te berekenen.

Maar, om nu elk record te doorlopen om te kijken wat de afstand is, komt natuurlijk niet ten goede van de performance.

Weet iemand hoe ik het bovenstaande het beste kan berekenen? Ik heb in de database de coordinaten al opgeslagen. Dus ik zou eigenlijk in mijn mysql query kunnen zoeken op bijvoorbeeld: LIKE Lat = 1234'%' ,,, maar hoe dit te berekenen?

En hoe gaat dat in zn werk ?

quote:

Op donderdag 18 juni 2009 18:21 schreef Likkende_Lassie het volgende:
En hoe gaat dat in zn werk ?

Je hebt die 300.000+ records in een database. Ik neem aan dat die dingen ook allemaal een eigen id hebben. Dan maak je een tabel aan met de velden id1, id2 en afstand (vergeet ook de indexen niet). En een scriptje om die tabel te vullen.

pseudocode:


Voordeel: je berekent iedere afstand maar 1 keer.
Nadeel: bij het opvragen van afstanden moet je er rekening mee houden dat het punt met het hoogste id altijd als tweede genoemd wordt.

je kan ze ook ALLEMAAL uitrekenen

Dus zowel de heenweg als de terugweg zeg maar... Dan voorkom je je nadeel, en heb je feitelijk de helft aan overbodige records

quote:

Op donderdag 18 juni 2009 19:45 schreef Xcalibur het volgende:
je kan ze ook ALLEMAAL uitrekenen

Dus zowel de heenweg als de terugweg zeg maar... Dan voorkom je je nadeel, en heb je feitelijk de helft aan overbodige records

Ja, ik had de drie weken vakantie nog maar niet genoemd

Ja maar... zo kan ik de afstand van slechts 1 startlocatie opslaan

Er zullen straks flink wat gebruikers verschillende startpunten gaan invoeren, waardoor de afstand per locatie scheelt. Toch?

Zoiets zou opzich wel moeten kunnen denk ik ja. Maar, hoe bereken je de lat/long die je in de SQL query gebruikt?

Kun je het niet generaliseren tot stad/dorp/iets groters dan de exacte coordinaten van de postcode, en een tabel maken die de afstand tussen die grotere blokken opslaat? Tenzij het erg is dat de meting niet 100% nauwkeurig is natuurlijk, dan is dat geen optie.. Mocht je de exacte afstand alsnog willen weten kun je alles selecteren waarbij de afstand tussen de 2 dorpen zegmaar <55km is, daar de exacte afstanden van berekenen, en dan alles <50km weergeven.. ofzoiets..

Ik wil een str_ireplace gebruiken om een link ergens omheen te zetten, maar hij moet het originele woord niet veranderen qua hoofd/kleine letters. Is dat mogelijk of wordt het een eregi oid?
Bijvoorbeeld "Dit IS eEn Test" wordt niet "dit is een test" (met link eromheen dan).

quote:

Op vrijdag 19 juni 2009 18:33 schreef splendor het volgende:
Ik wil een str_ireplace gebruiken om een link ergens omheen te zetten, maar hij moet het originele woord niet veranderen qua hoofd/kleine letters. Is dat mogelijk of wordt het een eregi oid?
Bijvoorbeeld "Dit IS eEn Test" wordt niet "dit is een test" (met link eromheen dan).

Ik zou preg_replace() gebruiken.

quote:

Op vrijdag 19 juni 2009 19:09 schreef Light het volgende:

[..]

Ik zou preg_replace() gebruiken.

Lekker goed voor de performance ook
Aangezien de functionaliteit in php (afaik) niet bestaat om hoofdletterongevoelig te vergelijken maar vervolgens wel de hoofdletters te behouden zou ik er gewoon een eigen functietje voor maken:

Stuk beter voor de performance dan een regular expression

quote:

Op vrijdag 19 juni 2009 23:51 schreef Intrepidity het volgende:

[..]

Lekker goed voor de performance ook
Aangezien de functionaliteit in php (afaik) niet bestaat om hoofdletterongevoelig te vergelijken maar vervolgens wel de hoofdletters te behouden zou ik er gewoon een eigen functietje voor maken:
[ code verwijderd ]

Stuk beter voor de performance dan een regular expression

Ik ben het met je eens dat het sneller is als je geen regular expression nodig hebt. Maar van de regular expression functies presteren de preg_* functies over het algemeen veel beter dan de ereg_* functies.

En jouw functie is leuk, maar werkt alleen als de input een exacte match is met de compare-tekst (hoofdletters buiten beschouwing gelaten). Met preg_replace() mag er ook tekst voor en/of achter de gezochte tekst staan en kun je toch een goede vervanging maken.

quote:

Op zaterdag 20 juni 2009 00:08 schreef Light het volgende:

[..]

Ik ben het met je eens dat het sneller is als je geen regular expression nodig hebt. Maar van de regular expression functies presteren de preg_* functies over het algemeen veel beter dan de ereg_* functies.

En jouw functie is leuk, maar werkt alleen als de input een exacte match is met de compare-tekst (hoofdletters buiten beschouwing gelaten). Met preg_replace() mag er ook tekst voor en/of achter de gezochte tekst staan en kun je toch een goede vervanging maken.

Goed punt, het is ook al laat Het is opzich wel werkend te krijgen met een stripos.. Maar tenzij je deze functionaliteit een paar 1000 keer op een pagina gebruikt is de tijdswinst zo minimaal dat je inderdaad beter af bent met een simpele regex

quote:

Op donderdag 18 juni 2009 17:30 schreef Likkende_Lassie het volgende:
Vraagje:

Ik heb de volgende functie om te berekenen hoeveel afstand er tussen 2 coordinaten zit:
[ code verwijderd ]

Echter, nu heb ik een database met +300.000 records.
Ik wil dat de gebruiker kan zeggen: ik wil binnen een straal van xx KM de resultaten zien.
Dat kunnen ze doen door een postcode in te vullen, waar ik een ander script voor heb om de coordinaten te berekenen.

Maar, om nu elk record te doorlopen om te kijken wat de afstand is, komt natuurlijk niet ten goede van de performance.

Weet iemand hoe ik het bovenstaande het beste kan berekenen? Ik heb in de database de coordinaten al opgeslagen. Dus ik zou eigenlijk in mijn mysql query kunnen zoeken op bijvoorbeeld: LIKE Lat = 1234'%' ,,, maar hoe dit te berekenen?

Wat is een te verwachten waarde voor de straal? 1km? 10km? 100km? Dit is namelijk heel erg bepalend voor hoeveel procent van je records je terug zou kunnen krijgen. Bij 100km zou je in theorie bijna alle locaties terug kunnen krijgen, dus dan heeft slim querien weinig zin, bijvoorbeeld.

Stel dat je straal maximaal zo'n 40 km is, dan zou je het volgende kunnen doen:
* Sla de lattitude op in z'n eigen kolom, met een aparte index op alleen deze kolom.
* Sla de longitude op in z'n eigen kolom, met een aparte index op alleen deze kolom.
* Als je gaat querien, gebruik dan niet de cirkel met een straal van X kilometer, maar het vierkant wat deze cirkel omsluit (oftewel "teken het kleinst mogelijke vierkant om de cirkel met straal X"). Het voordeel is dat je deze vierkant rechtstreeks kan gebruiken in je query ("WHERE Lat between 51,201 and 51,323 and Long between 54.30 and 54.37") en dat dit geoptimaliseerd kan door de indexen op de Lat en Long kolommen.
* De resultset die je terugkrijgt bevat nu nog wel punten die wel binnen het vierkant vielen, maar niet binnen de cirkel. Deze zul je er in code uit moeten filteren met de berekening die je postte, maar dat is niet zo erg, omdat dit slechts ong. 20% van je rijen zal betreffen - de overige 80% valt zowel binnen het vierkant als binnen de cirkel.

Dit lijkt me de best haalbare combinatie van een eenvoudige query die relatief weinig nutteloze rijen teruggeeft.

quote:

Op zaterdag 20 juni 2009 11:23 schreef GlowMouse het volgende:

[..]

Niet waar, ook met MySQL 5.x niet:
[..]

Hmm, volgens mij zou je dan het stuk over index intersections moeten quoten, en ik maak hieruit op dat MySQL dan wel beide indexen gebruikt?

Ik gebruik zelf geen MySQL, dus ik kan het niet testen, maar gelet op de documentatie (en mijn gevoel bij wat je van een redelijke RDBMS zou mogen verwachten) geef ik het eigenlijk wel een goede kans dat het wel geoptimaliseerd wordt.

quote:

Op zaterdag 20 juni 2009 11:46 schreef GlowMouse het volgende:

[..]

De enige ongelijkheid die ik zie staan daar is er eentje op een primary key van een InnoDB-tabel.

Oh, zo, ja dat zou ook kunnen. Ik lette met name op het feit dat alle condities met AND's gecombineerd moesten worden en dat per index al zijn kolommen in de conditie aanwezig moesten zijn. Daar lijkt mijn oplossing aan te voldoen, maar inderdaad, bij het gegeven voorbeeld gebruiken ze geen ongelijkheden.
Dus de vraag is of we daaruit moeten afleiden dat dit deel van het algoritme alleen met gelijkheden werkt.

quote:

Dat zal er wel mee te maken hebben dat die key bij elke entry in de index op key_col1 opgeslagen wordt, en MySQL dus eigenlijk alleen de index op key_col1 hoeft te raadplegen en daarbij direct en 'gratis' de ongelijkheid kan checken.

Ik heb een andere verklaring Ik denk dat InnoDB zijn primary key index altijd 'clustered' maakt, d.w.z. dat de records fysiek geordend op primary key worden opgeslagen. En wanneer gegevens fysiek gesorteerd opgeslagen zijn, is het heel efficient om een range query uit te voeren: je zoekt het beginpunt, het eindpunt, en je retourneert alle rijen ertussenin.

quote:

Queries op grote tabellen die geen resultaat kunnen geven op basis van maximaal één index, vermijd ik zelf liever bij webapplicaties.

De meeste webapplicaties gebruiken dan ook geen coordinaten