wat is beter: losse queries of in elkaar gevlegt q - Softwareontwikkeling

donderdag 16 mei 2002 22:31

Acties:

Ergo

Topicstarter

Aangezien ik een nieuwe site met PHP/MySQL wil bouwen met o.a. tabellen met usernames, gegevens en siteteksten. Vooral de usernames en gegevens zullen met elkaar in verband staan. Is het nu logischer om een grote query te bouwen waarin de username "vanzelf" naar boven komt drijven, of is het logischer eerst de UserID op te vragen en vervolgens in de tabel met Usernames de bijbehorende UserName te kiezen?

En waarom? Alvast bedankt.

donderdag 16 mei 2002 22:35

Acties:

whoami

Hangt ervan af.

Meestal doe ik het in 1 query, tenzij die echt zo groot wordt dat hij niet meer leesbaar is. 1 query -> 1x naar de databank gaan.

https://fgheysels.github.io/

donderdag 16 mei 2002 23:17

Acties:

Verwijderd

Als de database niet al te complex is (lijkt me in jouw geval), zul je er weinig aan merken wat je ook gebruikt..

donderdag 16 mei 2002 23:25

Acties:

Orphix

Je bedoelt gewoon een (inner) join

In dat geval zou ik altijd voor de joins gaan. Er is bij het aanvragen/parsen/verwerken van een query altijd overhead. In dit geval zou het onpraktisch zijn om 2 queries te gebruiken terwijl het makkelijk in 1 kan.

donderdag 16 mei 2002 23:25

Acties:

bille

Don't call me Buff

gezien je in MySQL geen joins kan maken voor zover ik weet zul je zowiezo met een subquery moeten werken. Waar je wel goed op moet letten is dat als je 2 of meerdere queries gaat gebruiken om je data bij elkaar te sprokkelen dat je dan 1 verbinding met de database openhoudt voor je queries die je snel achter elkaar wilt laten uitvoeren (en natuurlijk niet vergeten om ook weer de connectie te sluiten achteraf). Wat je natuurlijk altijd ff kan doen is de twee verschillende manieren in twee scripts verwerken en dan met het vergelijken van timestamps kijken wat het verschil in snelheid is tussen je queries

Wat je óók nog kan doen is ergens een scriptje vandaan halen waarmee je processtime van je querie kan opvragen aan MySQL. Een direkt linkie kan ik je helaas niet geven

Ultra Pilammo 6666Mhz AMD, 4251Mbit/s RAM, Gefors V6666 MegaTurbo, 43" TFS, Ultra 80Gig Firewire netwerkkaart en 5D geluid met 66 speakers in 5 dimensies

donderdag 16 mei 2002 23:33

Acties:

TromboneFreakus

Ergo

Topicstarter

Op donderdag 16 mei 2002 23:25 schreef bille het volgende:
gezien je in MySQL geen joins kan maken voor zover ik weet zul je zowiezo met een subquery moeten werken.

Geen inner joins? SQL is toch SQL? Vanwege de overzichtelijkheid maak ik meestal queries in Access, maar als ik het goed begrijp kan ik die NIET overnemen naar MySQL toe?

donderdag 16 mei 2002 23:38

Acties:

Creepy

Tactical Espionage Splatterer

MySQL ondersteunt nog geen sub-selects (sub queries). Maar joins zeker wel!

En joins zijn ook te maken zonder gebruik te maken van het keyword JOIN. (pak er eens een algemeen SQL boek bij.. staat het vast wel in..)

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

donderdag 16 mei 2002 23:40

Acties:

LuCarD

Certified BUFH

Op donderdag 16 mei 2002 23:25 schreef bille het volgende:
gezien je in MySQL geen joins kan maken voor zover ik weet zul je zowiezo met een subquery moeten werken.

Ermm geen joins???

MySQL kan goed inner/left/right joins doen

Op donderdag 16 mei 2002 22:31 schreef TromboneFreakus het volgende:
Aangezien ik een nieuwe site met PHP/MySQL wil bouwen met o.a. tabellen met usernames, gegevens en siteteksten. Vooral de usernames en gegevens zullen met elkaar in verband staan. Is het nu logischer om een grote query te bouwen waarin de username "vanzelf" naar boven komt drijven, of is het logischer eerst de UserID op te vragen en vervolgens in de tabel met Usernames de bijbehorende UserName te kiezen?

En waarom? Alvast bedankt.

Zeker een inner join gebruiken, das sneller en minder fout gevoelig.

Programmer - an organism that turns coffee into software.

vrijdag 17 mei 2002 00:20

Acties:

ACM

Software Architect

Werkt hier

Op donderdag 16 mei 2002 23:40 schreef LuCarD het volgende:
Zeker een inner join gebruiken, das sneller en minder fout gevoelig.

Persoonlijk heb ik een voorkeur voor equijoins waar mogelijk

(=).
Simpelweg omdat dat in de meeste gevallen het duidelijkst is en erg goed te optimaliseren (ja, wordt veelal naar een inner join geoptimaliseerd

).

vrijdag 17 mei 2002 00:24

Acties:

LuCarD

Certified BUFH

Op vrijdag 17 mei 2002 00:20 schreef ACM het volgende:

[..]

Persoonlijk heb ik een voorkeur voor equijoins waar mogelijk (=).
Simpelweg omdat dat in de meeste gevallen het duidelijkst is en erg goed te optimaliseren (ja, wordt veelal naar een inner join geoptimaliseerd ).

equijoin ???? ermm ???

* LuCarD pakt het grootte boze boek....

ahhh equijoin... http://www.va.pubnix.com/man/xdb/sqlref/Equijoin_282.html

Programmer - an organism that turns coffee into software.

vrijdag 17 mei 2002 00:28

Acties:

ACM

Software Architect

Werkt hier

Op vrijdag 17 mei 2002 00:24 schreef LuCarD het volgende:
equijoin ???? ermm ???

* LuCarD pakt het grootte boze boek....

ahhh equijoin... http://www.va.pubnix.com/man/xdb/sqlref/Equijoin_282.html

Moeilijk woord voor de meest gebruikte join

vrijdag 17 mei 2002 03:00

Acties:

Verwijderd

Op donderdag 16 mei 2002 22:31 schreef TromboneFreakus het volgende:
Aangezien ik een nieuwe site met PHP/MySQL wil bouwen met o.a. tabellen met usernames, gegevens en siteteksten. Vooral de usernames en gegevens zullen met elkaar in verband staan. Is het nu logischer om een grote query te bouwen waarin de username "vanzelf" naar boven komt drijven, of is het logischer eerst de UserID op te vragen en vervolgens in de tabel met Usernames de bijbehorende UserName te kiezen?

ligt eraan hoe goed je bent .. .

vrijdag 17 mei 2002 10:36

Acties:

whoami

Op donderdag 16 mei 2002 23:38 schreef Creepy het volgende:
En joins zijn ook te maken zonder gebruik te maken van het keyword JOIN. (pak er eens een algemeen SQL boek bij.. staat het vast wel in..)

Inderdaad, en dan zijn ze nog eens gemakkelijker te schrijven en nog leesbaarder ook!. Ik walg van die notatie waar je het JOIN keyword gebruikt, maar blijkbaar geldt hier op /14 ook de 80/20 regel wat betreft dat gebruik. 80% van de P&W'ers blijft aan dat JOIN keyword vasthouden, terwijl het waarschijnlijk geeneens ANSI SQL is.

https://fgheysels.github.io/

vrijdag 17 mei 2002 11:03

Acties:

LuCarD

Certified BUFH

Op vrijdag 17 mei 2002 10:36 schreef whoami het volgende:

[..]

Inderdaad, en dan zijn ze nog eens gemakkelijker te schrijven en nog leesbaarder ook!. Ik walg van die notatie waar je het JOIN keyword gebruikt, maar blijkbaar geldt hier op /14 ook de 80/20 regel wat betreft dat gebruik. 80% van de P&W'ers blijft aan dat JOIN keyword vasthouden, terwijl het waarschijnlijk geeneens ANSI SQL is.

Sorry maar JOIN is wel een ANSI SQL keyword...

zie hier
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

LET OP : Modem killer! 1,6 mb!!!!

thx FoxBoy. voor het melden

Programmer - an organism that turns coffee into software.

vrijdag 17 mei 2002 12:03

Acties:

Verwijderd

Op vrijdag 17 mei 2002 11:03 schreef LuCarD het volgende:

[..]

Sorry maar JOIN is wel een ANSI SQL keyword...

zie hier
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

Modem killer! 1,6 mb!!!!
(niet dat ik daar last van heb met mijn mxstream verbinding)

vrijdag 17 mei 2002 12:20

Acties:

raptorix

Op vrijdag 17 mei 2002 10:36 schreef whoami het volgende:

[..]

Inderdaad, en dan zijn ze nog eens gemakkelijker te schrijven en nog leesbaarder ook!. Ik walg van die notatie waar je het JOIN keyword gebruikt, maar blijkbaar geldt hier op /14 ook de 80/20 regel wat betreft dat gebruik. 80% van de P&W'ers blijft aan dat JOIN keyword vasthouden, terwijl het waarschijnlijk geeneens ANSI SQL is.

LOL

vrijdag 17 mei 2002 13:08

Acties:

whoami

Op vrijdag 17 mei 2002 12:20 schreef raptorix het volgende:

LOL

https://fgheysels.github.io/

vrijdag 17 mei 2002 20:25

Acties:

Orphix

Op vrijdag 17 mei 2002 10:36 schreef whoami het volgende:
Inderdaad, en dan zijn ze nog eens gemakkelijker te schrijven en nog leesbaarder ook!. Ik walg van die notatie waar je het JOIN keyword gebruikt, maar blijkbaar geldt hier op /14 ook de 80/20 regel wat betreft dat gebruik. 80% van de P&W'ers blijft aan dat JOIN keyword vasthouden, terwijl het waarschijnlijk geeneens ANSI SQL is.

Ohja? Ik heb juist eerder het gevoel dat het andersom is hier.
Een equijoin is idd 'logischer' wanneer je voor het eerst een query intypt. Alleen ik vind dat je dmv expliciete JOINS weer duidelijker kan zien hoe de relaties precies liggen. Het ligt een beetje aan de complexiteit.
Ik zou het trouwens erg raar vinden wanneer (vergelijkbare) innerjoins langzamer zouden zijn dan equijoins?

vrijdag 17 mei 2002 20:33

Acties:

djc

Op vrijdag 17 mei 2002 20:25 schreef Orphix het volgende:
Alleen ik vind dat je dmv expliciete JOINS weer duidelijker kan zien hoe de relaties precies liggen. Het ligt een beetje aan de complexiteit.

Ik vind de syntax-zonder-JOIN veel beter, omdat die intuitiever is. Vrijwel iedereen zal onmiddelijk begrijpen wat er bedoeld wordt, terwijl dat bij de JOIN nog best wel eens tegen zou kunnen vallen.

Rustacean

vrijdag 17 mei 2002 21:02

Acties:

Orphix

Op vrijdag 17 mei 2002 20:33 schreef Manuzhai het volgende:
Ik vind de syntax-zonder-JOIN veel beter, omdat die intuitiever is. Vrijwel iedereen zal onmiddelijk begrijpen wat er bedoeld wordt, terwijl dat bij de JOIN nog best wel eens tegen zou kunnen vallen.

Achja de join versie is wel iets 'netter' omdat het de relaties en de 'voorwaarden' van elkaar gescheiden houdt.
Maar zoals eerder gezegd, ik gebruik ook beiden, het ligt er maar gewoon aan welke het overzichtelijkst is.

zaterdag 18 mei 2002 11:13

Acties:

bille

Don't call me Buff

hm ok mijn fout.. tijdje geleden dat ik werkte met mysql en dacht dat de joins toen iig nog niet functioneerde in MySQL... * bille appoligies.

Ik vraag me wel af of een innerjoin dan wel sneller is gezien de SQL engine lijkt me dan de join omzet naar een subquery.. maarja das een aanname, om het zeker te weten zou je ff de handleiding erbij moeten pakken of testen met een optimizer tool

http://www.mysql.com/doc/Q/u/Query_Speed.html check daar ff voor query optimalizatie in MySQL...

Ultra Pilammo 6666Mhz AMD, 4251Mbit/s RAM, Gefors V6666 MegaTurbo, 43" TFS, Ultra 80Gig Firewire netwerkkaart en 5D geluid met 66 speakers in 5 dimensies

zaterdag 18 mei 2002 12:12

Acties:

Verwijderd

Het voordeel van 1 grote query die hetzelfde resultaat geeft is dat je de query optimizer van je dbms de gelegenheid geeft om zelf te bepalen welke manier hij kiest aan de hand van tabel grootte, aanwezigheid van indexen, etc, etc.

Bovendien zal het programmeren van 1 query eenvoudiger zijn dan kleine queries en eigen loopjes, etc.

Mocht je je query in de vorm van subqueries doen, bedenk dan dat het optimaliseren dan een stuk lastiger wordt en je dmbs dat misschien niet goed kan doen.