[SQL] Query-probleempje

[Verwijderd]

Goedeavond,

Voor een schoolproject moeten we een reserveringssysteem ontwikkelen in Java. Connectie met een database is daarbij zelfstudie. Tot hier nog toe liep alles vlotjes, maar nu heb ik een vrij complexe query nodig.

Ik moet van een reservatie, de eerste volgende reservatie oproepen van een bepaald lid...
Hiervoor heb ik al volgende SQL-string opgesteld ::

SELECT * FROM `Reservatie` WHERE user_id = ? AND (datum > NOW())


Deze heeft echter meerdere items terug terwijl ik slechts een mag hebben. Je kan dit eenvoudig oplossen in Java door enkel de eerste record te gebruiken, maar ik had graag gehad dat dit iets efficiënter verliep.

In de handboeken en op internet vind ik veel informatie, waardoor ik de bomen door heb bos niet meer zie...
Daarom had ik graag ietwat de juiste richting gekend waar ik precies moet naar zoeken.


Dank bij voorbaat,

Mathias Lavaert

[CodeCaster]

Je zou kunnen beginnen met vertellen met welk dialect SQL je gebruikt, bijvoorbeeld een van Microsoft, of toch meer richting MySQL, PGSQL of wellicht Oracle? De manier om het aantal geretourneerde records te beperken of om slechts de bovenste paar records te tonen verschilt namelijk nogal onderling.

En besides, dit is, geloof me, geen complexe query.

[NMe]

Dan zul je toch eerst eens moeten bepalen wélk record je dan terug wil hebben. De nieuwste? De oudste? Die waar aan een bepaalde andere voorwaarde voldaan wordt?

Verder heb je in MySQL hiervoor LIMIT en in MSSQL heb je TOP. Afhankelijk van je SQL-dialect kun je verschillende constructies verzinnen maar als je niet vertelt DBMS je gebruikt kunnen we je niet verder helpen.

[Blorgg]

Je zou een subquery aan je query toe kunnen voegen die de laatste datum van de voorgaande reserveringen voor een user ophaalt.

Reservatie? Het zijn geen indianen

[Grijze Vos]

Volgens mij ontkom je niet aan een subquery als je een enkel record terug wilt krijgen. De vraag is dan of dat daadwerkelijk efficienter is dan een simpele order by gecombineerd met een limit. (Of eender welke paging syntax gebruikt wordt.)

[Verwijderd]

Als database gebruiken we een MS Access databank... + In java gebruiken we een prepared statement

Ik heb de eerstvolgende record nodig met een datum na vandaag...


PS: Bedankt voor de snelle reachties ondertussen

[ Voor 14% gewijzigd door Verwijderd op 26-04-2010 00:32 ]

[Verwijderd]

Ik denk dat ik een mogelijke oplossing heb gevonden door met de SQL-functie FIRST te werken
Daarmee krijg ik de eerste in rij en inderdaad zoals hierboven vermeld een order by te doen

[creator1988]

Verwijderd schreef op maandag 26 april 2010 @ 00:40:
Ik denk dat ik een mogelijke oplossing heb gevonden door met de SQL-functie FIRST te werken
Daarmee krijg ik de eerste in rij en inderdaad zoals hierboven vermeld een order by te doen

Access kent volgens mij gewoon een 'TOP 1'?

code:

SELECT TOP 1 * FROM tabel WHERE ... ORDER BY ...

[whoami]

Grijze Vos schreef op maandag 26 april 2010 @ 00:17:
Volgens mij ontkom je niet aan een subquery als je een enkel record terug wilt krijgen. De vraag is dan of dat daadwerkelijk efficienter is dan een simpele order by gecombineerd met een limit. (Of eender welke paging syntax gebruikt wordt.)

Waarom ?
Met het limiteren van je resultset icm een sortering kom je er ook.

code:

SELECT TOP 1 * FROM reservatie WHERE userId = ? ORDER BY EenOfAndereDatum

/laat

[Verwijderd]

dat er op scholen nog met MS Access gewerkt wordt..... mag worden 10 jaar geleden oke, maar er zijn nu zoveel fatsoenlijke alternatieven. Zelfs Oracle licenties zijn gratis te krijgen.

[NMe]

Verwijderd schreef op maandag 26 april 2010 @ 14:22:
dat er op scholen nog met MS Access gewerkt wordt..... mag worden 10 jaar geleden oke, maar er zijn nu zoveel fatsoenlijke alternatieven. Zelfs Oracle licenties zijn gratis te krijgen.

Alsof Access niet meer dan voldoende is om iemand SQL aan te leren. Waarom zou je Oracle met al zijn honderden features gebruiken om je studenten alleen maar te verwarren terwijl ze de eerste tijd nog wel prima zoet zullen zijn met de standaardfeatures die Access ook biedt? Beetje kort door de bocht, dit.

[PolarBear]

Dat mensen nog steeds Access onderschatten. Het is een prima database zeker voor kleine hobby en schooldingen. Verschillen in dialect en gebruik heb je, ondanks de SQL standaard, toch wel. MySQL wat je ook veel ziet is ook zeker niet zaligmakend.

[Verwijderd]

Ik vind het zelf ook redelijk zielig om met Access te moeten werken... MySQL zou een beter alternatief zijn, al dan niet met MySQL Administrator als ze dan toch per se een grafische interface willen om de database te managen.

En de ODBC-JDBC driver voor Access is ook niet alles hoor...

[NMe]

Verwijderd schreef op maandag 26 april 2010 @ 17:51:
Ik vind het zelf ook redelijk zielig om met Access te moeten werken... MySQL zou een beter alternatief zijn, al dan niet met MySQL Administrator als ze dan toch per se een grafische interface willen om de database te managen.

Access dwingt tenminste nog af dat je GROUP BY netjes gebruikt zoals het hoort... Succes met mensen leren hoe dat werkt als elke fout die je daarmee werkt gewoon geslikt wordt.

[Grijze Vos]

whoami schreef op maandag 26 april 2010 @ 14:21:
[...]

Waarom ?
Met het limiteren van je resultset icm een sortering kom je er ook.

Of je leest de tweede zin van mijn post? :x

[cariolive23]

Verwijderd schreef op maandag 26 april 2010 @ 17:51:
Ik vind het zelf ook redelijk zielig om met Access te moeten werken... MySQL zou een beter alternatief zijn, al dan niet met MySQL Administrator als ze dan toch per se een grafische interface willen om de database te managen.

Dan heb je blijkbaar geen idee hoe SQL (de taal) moet werken, daar heeft MySQL veel grotere moeite mee dan dat Access dat heeft. MySQL doet dingen die helemaal niet kunnen, klinklare onzin zijn. Om dat nu te scharen in de categorie "beter alternatief"... Gebruik dan geen database, dat lijkt me een stuk veiliger.

Voer de volgende query maar eens uit, hoeveel appels levert dit volgens MySQL op?

SQL:

SELECT
  '2 appels' + ' nog een appel';

[NMe]

cariolive23 schreef op maandag 26 april 2010 @ 18:52:
[...]

Dan heb je blijkbaar geen idee hoe SQL (de taal) moet werken, daar heeft MySQL veel grotere moeite mee dan dat Access dat heeft. MySQL doet dingen die helemaal niet kunnen, klinklare onzin zijn. Om dat nu te scharen in de categorie "beter alternatief"... Gebruik dan geen database, dat lijkt me een stuk veiliger.

En ook dat is weer onzin. MySQL is geen beter alternatief dan Access, maar ook zeker niet per se slechter. Hou asjeblieft nou eens op met die kruistocht tegen MySQL, het begint oud te worden. Op dezelfde manier waarop je nu MySQL afschrijft vanwege één query (terwijl er een goed alternatief voor is, MySQL heeft de + gewoon niet geïmplementeerd voor concatenation) kan ik elk ander DBMS wel afschrijven op één enkele query.

[ Voor 15% gewijzigd door NMe op 26-04-2010 19:12 ]

[Manuel]

cariolive23 schreef op maandag 26 april 2010 @ 18:52:
[...]

Dan heb je blijkbaar geen idee hoe SQL (de taal) moet werken, daar heeft MySQL veel grotere moeite mee dan dat Access dat heeft. MySQL doet dingen die helemaal niet kunnen, klinklare onzin zijn. Om dat nu te scharen in de categorie "beter alternatief"... Gebruik dan geen database, dat lijkt me een stuk veiliger.

Voer de volgende query maar eens uit, hoeveel appels levert dit volgens MySQL op?

SQL:

SELECT
  '2 appels' + ' nog een appel';

Elke keer doe je het weer, altijd maar MySQL bashen. We weten inmiddels wel dat MySQL niet perfect is en dat is PosgresSQL ook niet dat je het even weet, hopelijk heb ik je even uit je droom geholpen. [/rage] MySQL kijkt naar of er een integer inzit en gaat die + doen in plaats van het er achter plakken. Indien je het als een string wilt gebruiken gebruik je toch gewoon CONCAT om het aan elkaar te plakken.

Want als je de onderstaande uitvoert krijg je gewoon 2+1=3.

SQL:

SELECT
  '2 appels' + '1 appel extra';

@TS: Gebruik gewoon wat voor de opdracht bedoelt is, in dit geval gewoon Access .

[cariolive23]

NMe schreef op maandag 26 april 2010 @ 19:10:
[...]
MySQL heeft de + gewoon niet geïmplementeerd voor concatenation

Waarom krijg je dan geen foutmelding bij een foute query? Dat is het andere alternatief en dat is zeer eenvoudig te implementeren. MySQL kan dat ook wel, maar dan moet je daar zelf om vragen. Dus de configuratie aanpassen.

kan ik elk ander DBMS wel afschrijven op één enkele query.

Zal ik nog even een stuk of 10 foute queries oplepelen die "resultaten" opleveren? Of ga je pas met 20, 30, 40 of 50 verschillende soorten foute queries akkoord? Zeg het maar, MySQL heeft meer dan genoeg bugs om dit aantal te halen.

Het is gewoon een verzameling bugs, niets meer en niets minder. Gebrek aan kennis bij de programmeur/opdrachtgever is vaak de enige reden dat men MySQL gebruikt, men hoopt dan met testen de meeste fouten uit de code te krijgen. Jammer dat er alleen geen prioriteit wordt gegeven aan testen, nog zo'n onderschoven kindje.


Ik ga voor de strafpunten...

[Davio]

Het begon met een gebruiker die een simpele query-vraag had en eindigt met een discussie over MySQL vs de rest, lijkt me niet echt nodig hier.

Als ik maar één record nodig heb gebruik ik met MySQL gewoon Limit. En met Progress gebruik ik Find First.

[Verwijderd]

Davio schreef op maandag 26 april 2010 @ 20:12:
Het begon met een gebruiker die een simpele query-vraag had en eindigt met een discussie over MySQL vs de rest, lijkt me niet echt nodig hier.

Inderdaad heb begint hier op een DBMS-Flame-wars te lijken. Maar eigelijk heb ik de oplossing reeds gevonden dank aan alle mensen die op mijn topic gereageerd hebben...

Maar nu mag er toch wel een slotje op.

[RobIII]

Verwijderd schreef op maandag 26 april 2010 @ 20:49:

Maar nu mag er toch wel een slotje op.

Een slotje is niet nodig op een topic als je je oplossing hebt. Zie daarvoor ook onze faq betreffende topiceinde. Daarbij is het wel zo fijn voor toekomstige lezers die je topic middels de search o.i.d. vinden als je even je oplossing post.

[NMe]

Ik zal er nog één keer op ingaan, maar alleen omdat dit topic toch "klaar" is.

cariolive23 schreef op maandag 26 april 2010 @ 19:49:
[...]

Waarom krijg je dan geen foutmelding bij een foute query? Dat is het andere alternatief en dat is zeer eenvoudig te implementeren. MySQL kan dat ook wel, maar dan moet je daar zelf om vragen. Dus de configuratie aanpassen.

Het is geen foute query. MySQL kan er prima mee rekenen, dus doet het dat ook. Als je dat niet wil, dan heb je inderdaad configs. Dat is niet meer dan de grenzen van je DBMS kennen en hoewel ik het met je eens ben dat het een maffe keus is, is het wel verdedigbaar.

[...]

Zal ik nog even een stuk of 10 foute queries oplepelen die "resultaten" opleveren? Of ga je pas met 20, 30, 40 of 50 verschillende soorten foute queries akkoord? Zeg het maar, MySQL heeft meer dan genoeg bugs om dit aantal te halen.

Jij noemt dingen bugs die geen bugs zijn. Volgens een bepaalde interpretatie van de standaard is de manier waarop MySQL omgaat met GROUP BY beter dan die van alle andere DBMS'en die ik ken omdat het daarin mogelijk is om bij de group by clause velden weg te laten die functioneel afhankelijk zijn van de velden waar je op groupt. Dat kun je niet fijn vinden, maar het staat daadwerkelijk zo in de standaard. Jij noemt het bug, MySQL noemt het, terecht, een feature.

Het is gewoon een verzameling bugs, niets meer en niets minder. Gebrek aan kennis bij de programmeur/opdrachtgever is vaak de enige reden dat men MySQL gebruikt, men hoopt dan met testen de meeste fouten uit de code te krijgen. Jammer dat er alleen geen prioriteit wordt gegeven aan testen, nog zo'n onderschoven kindje.

Leuke manier om zo'n beetje de hele webdevelopende wereld over één kam te scheren. Wij gebruiken op kantoor MySQL, en dat heeft niets te maken met gebrek aan kennis, noch bij onszelf, noch bij onze opdrachtgevers. Dat is een bewuste keuze die gemaakt is op basis van een kosten/baten-analyse en het feit dat iedereen bij ons op kantoor zich heel goed bewust is welke beperkingen en shortcuts er zijn. Je weet wel, die dingen die je ook van T-SQL, Oracle en PostgreSQL moet weten voordat je er écht fatsoenlijk mee kan werken.

Reken een developer niet af op de tools die hij kiest wanneer hij goede redenen heeft om ervoor te kiezen.