[PHP/(My)SQL] voor dummies #113

quote:

Op zondag 2 maart 2014 23:23 schreef henrivo het volgende:

[..]

Dat overweeg ik nu ook moet ik zeggen, als soort van tussenstap (ivm het leerproces). Aan te raden? Of juist niet? Anyone?

Niet als tussenstap, maar gewoon als framework voor de kleinere projecten. Scheelt een hoop ruimte en laadtijd.

quote:

Op maandag 3 maart 2014 09:41 schreef Maringo het volgende:

[..]

Niet als tussenstap, maar gewoon als framework voor de kleinere projecten. Scheelt een hoop ruimte en laadtijd.

Is dat echt iets waar je je sappel om moet maken? Bij "kleinere" projecten?
Ik zou het gebruiken als het makkelijker/sneller ontwikkelen is (kan ik me wel voorstellen, met SF2 ben je relatief veel tijd kwijt aan "overhead" wat voor single-file projectjes inderdaad tegen je kan werken). De rest is vooral placebo.

quote:

Op maandag 3 maart 2014 10:43 schreef KomtTijd... het volgende:

[..]

Is dat echt iets waar je je sappel om moet maken? Bij "kleinere" projecten?
Ik zou het gebruiken als het makkelijker/sneller ontwikkelen is (kan ik me wel voorstellen, met SF2 ben je relatief veel tijd kwijt aan "overhead" wat voor single-file projectjes inderdaad tegen je kan werken). De rest is vooral placebo.

Het is ook niet het enige verschil. Maar er zit duidelijk verschil tussen laadtijd van pagina's van Symfony2 en Silex. Dus ja, dat is iets waar ik me druk om maak. Met grotere projecten krijg je dat ook wel met Silex, vanwege onder andere de hoeveelheid aan modules die gebruikt worden. En daarom dus het genoemde verschil tussen de kleinere en grotere projecten.

Hallo hallo, ik ben net bezig met SQL en heb nu een vraagje. Ik zal het zo goed mogelijk proberen te omschrijven zodat mijn manier van denken te zien is:

-Ik heb een database met daarin een table met alle spelers van de eredivisie van een bepaalde tijd genaamd 'person'. Al deze spelers hebben oa een 'playerID' en een 'name'.
-Ook heb ik een table met alle clubs(club), welke ook oa een 'clubID' en een 'name' hebben.
-Daarnast nog een table met alle gespeelde matches(participation) met oa 'clubID' en 'playerID' zodat ik kan zien welke spelers er een bepaalde match gespeeld hebben voor hun club.

Stel ik wil nu alle spelers die voor de club Ajax gespeeld hebben als output krijgen.

Dan zal ik als eerst naar de table CLUB moeten gaan om te zoeken welke clubID Ajax heeft ->
SELECT clubID
FROM CLUB
WHERE NAME = 'Ajax'

De clubID is 1. Vervolgens kan ik dan in de participation table dit doen:

SELECT playerID
FROM PARTICIPATION
WHERE clubID = '1'

Dit geeft mij dan de lijst van alle spelers die voor club '1' gespeeld hebben.

Mijn eerste vraag is nu hoe ik er voor kan zorgen dat ik de clubID die ik in mijn 1e query heb opgevraagd door kan spelen naar mijn 2e query. Dus dat ik niet handmatig eerst de 1e query doe en daar '1' als uitkomst krijg en het vervolgens in de 2e query invul.

Mijn tweede vraag is hoe ik er voor kan zorgen dat ik van alle playerID's die ik heb opgevraagd de naam kan weergeven, zonder de query telkens te moeten aanpassen.
SELECT name
FROM PERSON
WHERE playerID ='x'
Waar x dan de playerID's zijn die ik net heb opgevraagd.
Bestaat er een FOR loop in SQL oid?

Ik hoop dat iemand me kan helpen, en mocht ik iets niet duidelijk genoeg hebben neergezet laat het me dan even weten!

quote:

Op maandag 3 maart 2014 13:07 schreef DannyDeko het volgende:
Dan zal ik als eerst naar de table CLUB moeten gaan om te zoeken welke clubID Ajax heeft ->
SELECT clubID
FROM CLUB
WHERE NAME = 'Ajax'

De clubID is 1. Vervolgens kan ik dan in de participation table dit doen:

SELECT playerID
FROM PARTICIPATION
WHERE clubID = '1'

Dit geeft mij dan de lijst van alle spelers die voor club '1' gespeeld hebben.

Mijn eerste vraag is nu hoe ik er voor kan zorgen dat ik de clubID die ik in mijn 1e query heb opgevraagd door kan spelen naar mijn 2e query. Dus dat ik niet handmatig eerst de 1e query doe en daar '1' als uitkomst krijg en het vervolgens in de 2e query invul.

De meeste databases zijn relatiedatabases; m.a.w. er worden tussen verschillende tabellen relaties gelegd door bijvoorbeeld IDs.

De twee queries kun je samenvoegen en een koppeling (relatie) maken door de IDs te koppelen.
Je kunt dit als één query schrijven door JOIN te gebruiken:
Omdat er met meerdere tabellen gewerkt wordt is het vaak handiger om aliassen te gebruiken in de query.
‘FROM CLUB c’ betekent dat de tabel CLUB de alias ‘c’ krijgt. Bij de verwijzing naar velden wordt dan deze alias gebruikt (‘c.clubID’). Je zou dit ook als ‘CLUB.clubID’ kunnen schrijven wanneer geen alias wordt gebruikt.

quote:

Op maandag 3 maart 2014 13:17 schreef d4v1d het volgende:
Voor de eerste
[ code verwijderd ]

Is even uit mn hoofd zo. Zit nu mobiel.

Daar heb je joins voor.

quote:

Op vrijdag 28 februari 2014 19:09 schreef CrashO het volgende:

[..]

$link binnen je functie `test` gaat niet werken. Die zit in een andere scope. Als je hem daar wilt gebruiken zal je hem moeten meegeven. (of OO gaan en een property binnen je class aanspreken )

SPOILER

Om spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.

Waarom werkt $link dan wel als het niet in een functie zit? Ik zie de logica er niet van.

quote:

Op maandag 3 maart 2014 16:22 schreef d4v1d het volgende:

[..]

Wat is er dan mis met subquerys? Waarom zijn joins zoveel beter?

(Ik heb t zo gevonden ooit, en sindsdien zo gedaan:@)

Joins zijn technisch veel sneller, mits je constraints, indexes enzo goed zijn. Sub queries zijn soms debiel traag, zeker als je NOT IN enzo gaat gebruiken.

Dan maakt het bij een simpele Wordpress niet uit, maar als je over een paar miljoen records gaat dan gaat het wel meetellen.

quote:

Op maandag 3 maart 2014 16:22 schreef d4v1d het volgende:

[..]

Wat is er dan mis met subquerys? Waarom zijn joins zoveel beter?

(Ik heb t zo gevonden ooit, en sindsdien zo gedaan:@)

Joins zijn sneller en subqueries lezen lelijk (al ken ik genoeg mensen die het juist andersom vinden).

quote:

Op maandag 3 maart 2014 16:54 schreef Diabox het volgende:

[..]

Joins zijn sneller en subqueries lezen lelijk (al ken ik genoeg mensen die het juist andersom vinden).

1) niet waar en 2) subjectief. JOINs zijn niet per definitie sneller, dat is van talloze factoren afhankelijk.

quote:

Op maandag 3 maart 2014 19:47 schreef papernote het volgende:

[..]

1) niet waar en 2) subjectief. JOINs zijn niet per definitie sneller, dat is van talloze factoren afhankelijk.

JOINs zijn wel beter te optimaliseren voor MySQL. Bij een subquery moet eerst die subquery worden gedaan voordat de hoofdquery uitgevoerd kan worden, terwijl MySQL bij een JOIN zelf kan bepalen welke tabel eerst gefilterd wordt. Goede indexes zijn uiteraard belangrijk.

quote:

Op maandag 3 maart 2014 19:47 schreef papernote het volgende:

[..]

1) niet waar en 2) subjectief. JOINs zijn niet per definitie sneller, dat is van talloze factoren afhankelijk.

Als jij niet gehandicapt je queries aan het schrijven bent zijn joins doorgaans sneller. En fantastische constatering dat het tweede subjectief is, volgens mij liet ik dat ook al doorschemeren in m'n post en lijkt me dat ook duidelijk.

quote:

Op maandag 3 maart 2014 19:47 schreef papernote het volgende:

[..]

1) niet waar en 2) subjectief. JOINs zijn niet per definitie sneller, dat is van talloze factoren afhankelijk.

ok, ok, joins zijn slechts in 99,9% van de gevallen aanzienlijk sneller.

En voor zoiets simpels als het voorbeeld waar het over ging, absoluut. Er is geen enkele reden om voor zoiets simpels een subquery te gebruiken.

Zo je zin?

Misschien handig: SQL Fiddle.
Keuze uit MySQL, SQLite, PostgreSQL, Oracle, MSSQL.

quote:

Op maandag 3 maart 2014 08:15 schreef Darkomen het volgende:
Klein vraagje, wat vinden de Zend certified mensen van deze cursus:
http://www.eduvision.nl/c(...)mpaign=php%20dag%205

Niemand die een opmerking? Heb nog maar tot de 8ste om te beslissen?

quote:

Op dinsdag 4 maart 2014 10:30 schreef Darkomen het volgende:

[..]

Niemand die een opmerking? Heb nog maar tot de 8ste om te beslissen?

Ben je al bekend met ZF? Als ik zo de omschrijving van de cursus lees zijn het ook dingen die je jezelf kunt aanleren door veel uit te proberen en de tutorial te volgen. Maar als je, zoals de omschrijving ook zegt, een "vliegende start" wilt is het wellicht een goed idee.

quote:

Op dinsdag 4 maart 2014 10:45 schreef papernote het volgende:

[..]

Ben je al bekend met ZF? Als ik zo de omschrijving van de cursus lees zijn het ook dingen die je jezelf kunt aanleren door veel uit te proberen en de tutorial te volgen. Maar als je, zoals de omschrijving ook zegt, een "vliegende start" wilt is het wellicht een goed idee.

bedankt voor je antwoord, nee helaas nog geen ervaring met ZF, wel codeigniter framework.

Ik heb het idee dat Symfony2 beter wordt opgenomen door de community dan ZF2. Waarom? Geen idee.

Omdat SF2

quote:

Op dinsdag 4 maart 2014 11:04 schreef Darkomen het volgende:

[..]

bedankt voor je antwoord, nee helaas nog geen ervaring met ZF, wel codeigniter framework.

Maar dan zul je vast al wel ervaring hebben met alle concepten (MVC ontwerppatroon, databases, authenticatie en autorisatie, caching, zoeken, webservices, JavaScript integratie en internationalisatie). Alleen dan niet in ZF maar in CI. Ik weet niet of het dan nog zo'n toegevoegde waarde heeft t.o.v. het zelf even aanleren middels de documentatie.

Als alle concepten je ook nog onbekend voor komen, dan is het wellicht wel goed.

quote:

Op dinsdag 4 maart 2014 20:01 schreef papernote het volgende:

[..]

Maar dan zul je vast al wel ervaring hebben met alle concepten (MVC ontwerppatroon, databases, authenticatie en autorisatie, caching, zoeken, webservices, JavaScript integratie en internationalisatie). Alleen dan niet in ZF maar in CI. Ik weet niet of het dan nog zo'n toegevoegde waarde heeft t.o.v. het zelf even aanleren middels de documentatie.

Als alle concepten je ook nog onbekend voor komen, dan is het wellicht wel goed.

Het voordeel van zo'n cursus is dat je na afloop kunt gaan zwaaien met een papiertje waarop staat dat je het geheel snapt(e).