[SQL] Gebruik van quotes bij cijfers *

[Verwijderd]

Ik ben dus bezig met sql en heb een aantal boeken etc gehaald om het te leren. Ben nu bezig met queries, maar het lukt me niet echt.

Ik heb een database met daarin een aantal tabellen gewoon met simpele gegevens erin.

De eerste query is mij gelukt. Rede hiervan is dat ik bij het from gedeelte gebruik moest maken van één tabel, maar zodra ik gebruik ga maken van twee tabellen gaat het volgens mij fout.

Voorbeeldje:

Ik wil een query die alle studentnamen weergeeft met hun telefoonnummer die een onvoldoende behaald hebben.

Hun namen en telefoonnummers staan in de tabel studenten. Hun cijfers in de tabel cijfers.

Ik dacht dan aan de volgende query:

SELECT [studentnaam], [telefoonnr], [cijfer]
FROM student, cijfers
WHERE cijfer= "<6";

Waarom ik denk dat het zo moest? Ik moet de naam en het telefoonnummer hebben dus geef ik die bij select weer. Deze 2 komen dus uit de tabel student. Ik moet ook het cijfer weten om de onvoldoende te bepalen, dus geef ik ook het cijfer weer bij select.

Deze gegevens worden gehaald uit de tabellen student en cijfers dus zet ik die neer bij from!

Ik moet weten wanneer het cijfer een onvoldoende is dus cijfer= "<6";

Maar ik krijg dan een popup veldje dat iets zegt van data typ mismatch in critical expresion:(

Ik weet dat het er misschien voor de pro's amateuristisch uitziet, maar ik wil het graag leren en ik word gek dat ik er niet uit kom!

Wat doe ik fout?

[Soultaker]

De reden dat je een die foutmelding krijgt, is dat cijfer="<6" geen geldige expressie is. cijfer<"6" is dat wel. Daarmee zou je tenminste een hele rij resultaten moeten krijgen. Nog niet de goede resultaten, en dat komt omdat een selectie op meerdere tabellen als resultaat het carthesisch product van die tabellen oplevert. Je hebt een extra beperking in de where-clause nodig om alleen de corresponderende velden uit de twee tabellen naast elkaar te krijgen.

[ Voor 6% gewijzigd door Soultaker op 01-06-2004 21:38 ]

[P_de_B]

mismatch in critical expresion:

Dat zegt íe vast niet

Dit is erg basic SQL. Je moet eens proberen in je boeken / op internet te zoeken op JOINS, dat is precies wat je nodig hebt. Ik ga het iig niet voorkauwen. Succes!

[gorgi_19]

een cijfer is geen string. Oftewel: "1" is niet gelijk aan 1 . Kijk anders ook even naar het gedeelte over joins in P&W FAQ - SQL

Met deze informatie moet je er waarschijnlijk wel uit kunnen komen. Succes.

edit:

tsjesus, speel ik even spuit 11

[ Voor 78% gewijzigd door gorgi_19 op 01-06-2004 21:38 ]

[Soultaker]

P_de_B: niet te ver doordenken. De TS krijgt die foutmelding vast wél! Als die verholpen is, is 'ie inderdaad nog niet klaar, maar dat komt daarna pas.

gorgi_19: onzin, elke SQL server die ik ken accepteert getallen als je er quotes omheen zet. Het kan dus absoluut geen kwaad (en is wel makkelijk als je je invoer van de gebruiker krijgt).

[Verwijderd]

Soultaker schreef op 01 juni 2004 @ 21:36:
De reden dat je een die foutmelding krijgt, is dat cijfer=<"6" geen geldige expressie is. cijfer<"6" is dat wel. Daarmee zou je tenminste een hele rij resultaten moeten krijgen. Nog niet de goede resultaten, en dat komt omdat een selectie op meerdere tabellen als resultaat het carthesisch product van die tabellen oplevert. Je hebt een extra beperking in de where-clause nodig om alleen de corresponderende velden uit de twee tabellen naast elkaar te krijgen.

Mijn held hij werkt nu!!!

[Janoz]

Wat je nu doet is de waarde van het cijfer vergelijken met de string "<6". Je bent nu dus de tekst "<6" aan het vergelijken met het getal dat het cijfer aangeeft. Wat je waarschijnlijk bedoeld is gewoon cijfer < 6. Dan kijk je of het cijfer kleiner is dat 6.

Nog een paar andere puntjes:
Geef ook aan uit welke tabellen de verschillende velden komen. Hoe zou de db nu moeten weten of telefoonnr in de tabel student of de tabel cijfers staat? Dit doe je door student.studentnaam te doen ipv alleen studentnaam.
Als laatste geef je ook niet aan op welke manier een record uit de cijfer tabel gekoppeld moet worden aan een record uit de student tabel. Dit doe je mbv joins (kun je vast wel iets over vinden in die boeken ). Succes!

[P_de_B]

Soultaker schreef op 01 juni 2004 @ 21:38:
P_de_B: niet te ver doordenken. De TS krijgt die foutmelding vast wél! Als die verholpen is, is 'ie inderdaad nog niet klaar, maar dat komt daarna pas.

Ik ging inderdaad niet in op de foutmelding omdat ik al een andere fout zag. Niet helemaal correct idd. De foutmelding die hij typt geeft íe echter echt niet

gorgi_19: onzin, elke SQL server die ik ken accepteert getallen als je er quotes omheen zet. Het kan dus absoluut geen kwaad (en is wel makkelijk als je je invoer van de gebruiker krijgt).

Dat is anders precies de foutmelding datatype mismath in criteria expression. Het datatype komt niet overeen.

In SQL Server zal dit _{volgens mij} inderdaad goed gaan omdat SQL Server impliciet cast van string naar integer indien mogelijk. Accesb lijkbaar niet.

SQL Server 2000 vindt het trouwens ook absoluut niet leuk en geeft ook een foutmelding terug.

hmm, nu moet ik weer m'n werk laptop pakken om te controleren. Ik zou zweren dat dit wel kon. Wordt vervolgd

[ Voor 23% gewijzigd door P_de_B op 01-06-2004 21:49 ]

[gorgi_19]

Soultaker schreef op 01 juni 2004 @ 21:38:
gorgi_19: onzin, elke SQL server die ik ken accepteert getallen als je er quotes omheen zet. Het kan dus absoluut geen kwaad (en is wel makkelijk als je je invoer van de gebruiker krijgt).

Probeer het maar eens in MS Access; deze levert ook deze foutmelding op.

SQL:

SELECT Table3.kolom2
FROM Table3
WHERE (((Table3.kolom2)<"1"));

geeft de foutmelding;

code:

SELECT Table3.kolom2
FROM Table3
WHERE (((Table3.kolom2)<1));

doet het goed.

SQL Server 2000 vindt het trouwens ook absoluut niet leuk en geeft ook een foutmelding terug.

[ Voor 8% gewijzigd door gorgi_19 op 01-06-2004 21:43 ]

[Soultaker]

Hmz, blijkbaar is het dus nog redelijk productafhankelijk. Handig, die SQL standaard. Het gaat dus niet overal goed (maar ook zeker niet overal fout).

[whoami]

Zowiezo is het niet aan te raden om quotes te gebruiken als dit niet nodig is.

In Oracle is er bv. een serieuze performance - hit als je dit doet:

code:

SELECT *
FROM tabel
WHERE Mijnveld > "6"

(Ervan uitgaand dat Mijnveld een numeriek veld is). Dit werkt wel, in die zin dat de juiste resultaten weergegeven worden, maar doordat je die quotes daarzet moet er een conversie plaatsvinden, en zullen er geen indexen gebruikt worden, waardoor er een table-scan optreedt.

[Guldan]

SELECT [studentnaam], [telefoonnr], [cijfer]
FROM student, cijfers
WHERE cijfer= "<6";

zou moeten worden

SELECT student.[studentnaam], .student.[telefoonnr], cijfers.[cijfer]
FROM student, cijfers
WHERE cijfers.cijfer= <6;

Omdat je met meerdere tabellen werkt dan weet SQL niet uit welke tabel hij het moet halen. Daarom moet je de tabelnaam er voor zetten bla.woot bijv. Hij pakt nu de waarde woot uit de tabel bla. Ik hoop dat dit duidelijk is maar dit had ook in je boeken gestaan.

edit:


post ik gemaakt geheel aan de hand van janoz zijn tips... ik las weer te snel . Ik heb niets getest etc. maar ik geloof dat het klopt.

[ Voor 24% gewijzigd door Guldan op 01-06-2004 21:50 ]

[gorgi_19]

Zow, maar een kleine topictitlechange gedaan....

[gorgi_19]

P_de_B schreef op 01 juni 2004 @ 21:40:
hmm, nu moet ik weer m'n werk laptop pakken om te controleren. Ik zou zweren dat dit wel kon. Wordt vervolgd

Net uitgeprobeerd:

SQL:

Select * FROM ProSim_User WHERE UserID = "21"

Dan geeft hij aan dat hij kolom 21 niet kan vinden; hij beschouwd het dus als een referentie naar een kolom.

SQL:

Select * FROM ProSim_User WHERE UserID <= "UserID"

is daarentegen wel weer geldig volgens SQL Server 2k.

[whoami]

gorgi_19 schreef op 01 juni 2004 @ 21:51:
[...]

Net uitgeprobeerd:

SQL:

Select * FROM ProSim_User WHERE UserID = "21"

Dan geeft hij aan dat hij kolom 21 niet kan vinden; hij beschouwd het dus als een referentie naar een kolom.

SQL:

Select * FROM ProSim_User WHERE UserID <= "UserID"

is daarentegen wel weer geldig volgens SQL Server 2k.

En wat als je het met enkele quotes doet ? ( ' dus ).

[Verwijderd]

http://www.phpfreaks.nl <= daar staat een hééél goede tutorial over SQL.

[P_de_B]

gorgi_19 schreef op 01 juni 2004 @ 21:51:
[...]

Net uitgeprobeerd:

SQL:

Select * FROM ProSim_User WHERE UserID = "21"

Dan geeft hij aan dat hij kolom 21 niet kan vinden; hij beschouwd het dus als een referentie naar een kolom.

SQL:

Select * FROM ProSim_User WHERE UserID <= "UserID"

is daarentegen wel weer geldig volgens SQL Server 2k.

tsk, je moet single quotes gebruiken 'dus ipv " Ik heb het net getest en het werkt.

edit: wat whoami zegt dus. _{spuit 11}

[ Voor 9% gewijzigd door P_de_B op 01-06-2004 21:55 ]

[whoami]

Ik vraag me af of je bij SQL Server ook diezelfde performance hit ziet als bij Oracle, als je quotes gebruikt voor een numeriek veld en als er een index op dat veld ligt.

(Ja, ik ben te lui om QA op te starten, en eea uit te testen. ).

[P_de_B]

whoami schreef op 01 juni 2004 @ 21:57:
Ik vraag me af of je bij SQL Server ook diezelfde performance hit ziet als bij Oracle, als je quotes gebruikt voor een numeriek veld en als er een index op dat veld ligt.

(Ja, ik ben te lui om QA op te starten, en eea uit te testen. ).

Net getest, en het execution plan geeft geen verschillen. Er ligt wel een index op de kolom die ik heb geprobeerd. Ik weet niet of het bij een kolom zonder index wel een verschil uitmaakt.

[.oisyn]

guldan schreef op 01 juni 2004 @ 21:48:
[...]


zou moeten worden

code:

SELECT student.[studentnaam], .student.[telefoonnr], cijfers.[cijfer]
FROM student, cijfers
WHERE cijfers.cijfer= <6;

[...]

edit:


post ik gemaakt geheel aan de hand van janoz zijn tips... ik las weer te snel . Ik heb niets getest etc. maar ik geloof dat het klopt.

Daar klopt nog steeds niet van, haal die = maar weg

[whoami]

Of je doet < 6, of je doet <= 6, maar =< 6 bestaat niet, zoals hier al eerder verteld werd.

[ACM]

whoami schreef op 01 juni 2004 @ 21:47:
(Ervan uitgaand dat Mijnveld een numeriek veld is). Dit werkt wel, in die zin dat de juiste resultaten weergegeven worden, maar doordat je die quotes daarzet moet er een conversie plaatsvinden, en zullen er geen indexen gebruikt worden, waardoor er een table-scan optreedt.

Die redenatie is onzin, hoe Oracle het doet weet ik niet, maar de redenatie an sich is onzin...

Er moet inderdaad een conversie plaatsvinden, maar niets weerhoudt de DB ervan om "6" al bij het parsen of plannen van de query om te zetten naar de integer (of long, of ...) 6.
En om twee simpele voorbeelden te noemen, zowel MySQL als PostgreSQL accepteren het als je je 6 in een string stopt en geven je totaal geen performance-verlies.

Overigens doet SQL aan '-quotes voor strings, niet aan "-quotes, die zijn voor "speciale woorden die je wilt beschermen", zoals tabelnamen met een spatie enzo (waar MySQL de ` voor gebruikt).
Ik denk dat dat laatste eerder problematisch is en foutmeldingen oplevert, dan een getal dat als string wordt meegegeven

[gorgi_19]

whoami schreef op 01 juni 2004 @ 21:53:

En wat als je het met enkele quotes doet ? ( ' dus ).

MS Access blijft bokken; SQL Server heeft er geen problemen mee.. Alleen in het 'originele' probleem werd " genoemd ipv '

[Grijze Vos]

guldan schreef op 01 juni 2004 @ 21:48:
Omdat je met meerdere tabellen werkt dan weet SQL niet uit welke tabel hij het moet halen. Daarom moet je de tabelnaam er voor zetten bla.woot bijv. Hij pakt nu de waarde woot uit de tabel bla. Ik hoop dat dit duidelijk is maar dit had ook in je boeken gestaan.

Niet echt. Zolang je join / cartesisch product geen ambigue naamgevingen heeft is het niet nodig de tabel te benoemen.

voorbeeldje:

code:

tabel1:
idblaat  :: INTEGER
blap    :: TEXT

tabel2:
id       :: INTEGER
blab      :: TEXT

tabel3:
idblaat  :: INTEGER
blabpq :: TEXT

Als je tabel 1 en 2 met elkaar combineert zijn alle velden uniek, en hoef je nergens die tabel te benoemen.

Als je tabel 1 en 3 combineert, moet je tabel1.idblaat en tabel3.idblaat gebruiken. (Ik weet niet zeker of het ook moet als je joined op idblaat, dan zou het wel eens kunnen dat het niet meer hoeft. Ik meen namelijk dat idblaat dan ook maar 1x in de resultset terechtkomt.

[Kama]

Soultaker schreef op 01 juni 2004 @ 21:45:
Hmz, blijkbaar is het dus nog redelijk productafhankelijk. Handig, die SQL standaard. Het gaat dus niet overal goed (maar ook zeker niet overal fout).

Standaard? Die S staat voor Structured, niet voor Standard... Een bekende misvatting

SQL is niet standaard....

[Soultaker]

Wat loopt de ISO zich er dan tegenaan te bemoeien met hun specificaties? Het idee was toch wel om een sortement van standaardachtige SQL te maken, dacht ik, maar elke keer gaat het weer op de meest stompzinnige punten mis (zo ook hier). </rant>

[ Voor 5% gewijzigd door Soultaker op 02-06-2004 01:40 ]

[curry684]

Kama schreef op 02 juni 2004 @ 01:19:
[...]


Standaard? Die S staat voor Structured, niet voor Standard... Een bekende misvatting

SQL is niet standaard....

SQL is wel degelijk een ANSI/ISO standaard, dat de S in de afko ergens anders voor staat heeft daar geen bal mee van doen. Zie http://www.techstreet.com/features/ISO_IEC_9075.tmpl voor de exacte teksten.

[whoami]

ACM schreef op 01 juni 2004 @ 22:26:
[...]

Die redenatie is onzin, hoe Oracle het doet weet ik niet, maar de redenatie an sich is onzin...

Er moet inderdaad een conversie plaatsvinden, maar niets weerhoudt de DB ervan om "6" al bij het parsen of plannen van de query om te zetten naar de integer (of long, of ...) 6.
En om twee simpele voorbeelden te noemen, zowel MySQL als PostgreSQL accepteren het als je je 6 in een string stopt en geven je totaal geen performance-verlies.

Hmm, ik heb hier net even zitten testen en blijkbaar worden er nu ook indexen gebruikt (met quotes dus).

Overigens doet SQL aan '-quotes voor strings, niet aan "-quotes, die zijn voor "speciale woorden die je wilt beschermen", zoals tabelnamen met een spatie enzo (waar MySQL de ` voor gebruikt).

idd.

[ACM]

Soultaker schreef op 02 juni 2004 @ 01:40:
Wat loopt de ISO zich er dan tegenaan te bemoeien met hun specificaties? Het idee was toch wel om een sortement van standaardachtige SQL te maken, dacht ik, maar elke keer gaat het weer op de meest stompzinnige punten mis (zo ook hier).

Wat is er niet goed aan dan

[Soultaker]

ACM schreef op 02 juni 2004 @ 10:51:
Wat is er niet goed aan dan

Dat het praktisch onmogelijk blijkt om queries te schrijven die op verschillende databaseservers werken. Dat lijkt me nu juist een erg nuttig doel van de standaardisatie. Misschien komen die incompatibiliteiten door allemaal specifieke extensies op de standaard, maar dan vind ik het nog erg jammer dat het voor zover ik weet niet mogelijk is om in een 'standard compliant' modus te werken. Ik zou het als gebruiker veel prettiger vinden als de query parser mijn queries die niet aan de standaard voldoen zou verwerpen, dan dat 'ie z'n uiterste best gaat doen om 'm toch nog op de een of andere serverspecifieke manier te interpreteren.

[ Voor 45% gewijzigd door Soultaker op 02-06-2004 14:10 ]

[cameodski]

Soultaker schreef op 02 juni 2004 @ 14:07:
[...]

Dat het praktisch onmogelijk blijkt om queries te schrijven die op verschillende databaseservers werken. Dat lijkt me nu juist een erg nuttig doel van de standaardisatie. Misschien komen die incompatibiliteiten door allemaal specifieke extensies op de standaard, maar dan vind ik het nog erg jammer dat het voor zover ik weet niet mogelijk is om in een 'standard compliant' modus te werken. Ik zou het als gebruiker veel prettiger vinden als de query parser mijn queries die niet aan de standaard voldoen zou verwerpen, dan dat 'ie z'n uiterste best gaat doen om 'm toch nog op de een of andere serverspecifieke manier te interpreteren.

Tja, misschien komt het wel doordat er nog van alles aan ontbrak en er een aantal grote bedrijven het vervolgens ook niet nuttig vonden om met elkaar te overleggen, opdat de overstap naar een ander RDBMS in ieder geval niet al te makkelijk is
Of redeneer ik nu een beetje te zwart-wit?

edit:

Even typefout verbeteren

[ Voor 6% gewijzigd door cameodski op 02-06-2004 14:44 ]

[curry684]

cameodski schreef op 02 juni 2004 @ 14:22:
[...]

Tja, misschien komt het wel doordat er nog van alles aan ontbrak en er een aantal grote bedrijven het vervolgens ook niet nuttig vonden om met elkaar te overleggen, omdat opdat de overstap naar een ander RDBMS in ieder geval niet al te makkelijk is
Of redeneer ik nu een beetje te zwart-wit?

Zat 1 lettertje fout

[ACM]

Soultaker schreef op 02 juni 2004 @ 14:07:
Dat het praktisch onmogelijk blijkt om queries te schrijven die op verschillende databaseservers werken.

Met een beetje moeite lukt het wel hoor bij de nieuwste producten, maar dat betekent wel dat je ook moet proberen naar de standaard toe te schrijven. Dus geen [] om tabelnamen enzo.

Dat lijkt me nu juist een erg nuttig doel van de standaardisatie.

't Is net als met HTML, iedereen implementeert "een groot deel van de standaard", maar niet iedereen hetzelfde deel en ook niet iedereen doet dat op dezelfde manier. Al met al is dat inderdaad een groot nadeel bij het "aanhouden van standaarden", maar niet specifiek iets voor SQL. Hoewel de geschiedenis van SQL al wat langer is en je wellicht daardoor meer van dit soort rare dingen tegenkomt.
Maar bij mijn weten zijn de databases redelijk compatibel als het gaat om het meegeven van variabelen.
Maar helaas zijn er dan weer van die dbms-en die er net weer wat andersmee omgaan, stricter bijvoorbeeld zoals DB2.

Misschien komen die incompatibiliteiten door allemaal specifieke extensies op de standaard, maar dan vind ik het nog erg jammer dat het voor zover ik weet niet mogelijk is om in een 'standard compliant' modus te werken.

Sommige databases kunnen trouwens in SQL92, SQL89 of andere (eigen) varianten werken, schakelbaar op de connectie/in de configuratie.

Ik zou het als gebruiker veel prettiger vinden als de query parser mijn queries die niet aan de standaard voldoen zou verwerpen, dan dat 'ie z'n uiterste best gaat doen om 'm toch nog op de een of andere serverspecifieke manier te interpreteren.

Volgens mij mikken de meeste databases alle queries die ze niet toestaan gewoon weg hoor, er zijn wat kleine dingen waar de standaard de boel niet bepaald (zoals de sortering van NULL-waarden).
't Nadeel is, denk ik, meer de gebruiker die leert omgaan met een databasesysteem, ipv met SQL (en daarmee in theorie alle dbms-en). Als je bijvoorbeeld door je DBMS gedwongen werd om left joins met *= of += te schrijven (oid, oracle deed iets met een *, ms/sybase iets met += en =+ meen ik), dan zal je dat zo aanleren en niet zo gauw - als dat later mogelijk wordt - ineens de standaardmethode gebruiken...

[Kama]

curry684 schreef op 02 juni 2004 @ 02:57:
[...]

SQL is wel degelijk een ANSI/ISO standaard, dat de S in de afko ergens anders voor staat heeft daar geen bal mee van doen. Zie http://www.techstreet.com/features/ISO_IEC_9075.tmpl voor de exacte teksten.

Ok, heel fijn dat er een ISO specificatie van is, maar heb jij al twee databases gezien die precies dezelfde SQL ondersteunen? Ik niet. Dus ik zou ook geen standaard SQL aan kunnen wijzen. Dus imo bestaat er geen standaard.

Overigens die standaarden op de URL van je zijn niet te lezen zonder ervoor te moeten betalen. Wat heb je nou aan een "standaard" die niet open is?

[whoami]

Kama schreef op 03 juni 2004 @ 21:37:
[...]


Ok, heel fijn dat er een ISO specificatie van is, maar heb jij al twee databases gezien die precies dezelfde SQL ondersteunen? Ik niet. Dus ik zou ook geen standaard SQL aan kunnen wijzen. Dus imo bestaat er geen standaard.

Hmmm, er is ook een C++ standaard, maar de Borland implementatie en Microsoft implementatie heeft ook verschillende keywords er aan toegevoegd.
Dat is ook zo met SQL.

Ieder DBMS begrijpt een SELECT ... FROM ... WHERE ..., een INSERT, etc.... Het enige waarin ze verschillen zijn specifieke toevoegingen.

[ACM]

whoami schreef op 03 juni 2004 @ 21:55:
Ieder DBMS begrijpt een SELECT ... FROM ... WHERE ..., een INSERT, etc.... Het enige waarin ze verschillen zijn specifieke toevoegingen.

Mja, ook in dingen die niet al te expliciet in die standaarden staan, dingen die erg lastig te implementeren zijn en dingen die voorheen niet in de standaarden zaten.

Ik geloof dat er nu met sql03 pas een procedurele taal vastgelegd is, maar er is uiteraard nog geen enkele implementatie van sql03 beschikbaar, hooguit deelimplementaties (ik weet dat ze bij postgres wat moeite doen meer sql03 conform te raken en gelukkig al behoorlijk sql92/99 conform waren geworden).

[curry684]

Kama schreef op 03 juni 2004 @ 21:37:
[...]


Ok, heel fijn dat er een ISO specificatie van is, maar heb jij al twee databases gezien die precies dezelfde SQL ondersteunen? Ik niet. Dus ik zou ook geen standaard SQL aan kunnen wijzen. Dus imo bestaat er geen standaard.

Als jij je aan de basissyntax houdt werken al jouw queries perfect op zowel SQL Server als Oracle. Dat je dan bijv. geen SELECT INTO moet gebruiken in TransactSQL (het heeft zelfs een ander naampje!) spreekt vanzelf, net zoals het Microsoft vanzelfsprekend vrijstaat om dit soort handige features toe te voegen. Maar 'SELECT * FROM MyTable;' is echt wel gestandaardiseerd hoor.

Overigens die standaarden op de URL van je zijn niet te lezen zonder ervoor te moeten betalen. Wat heb je nou aan een "standaard" die niet open is?

Iedere ANSI/ISO standaard is open maar moet je voor de exacte 900 pagina's beschrijvende tekst betalen. Met een korte Google-sessie kun je zelf ook wel een pagina vinden die gratis de samenvatting aanbiedt.

[drm]

Is het niet zo dat de meeste documentaties van verschillende SQL software zelf wel aangeven wanneer iets volgens de ANSI standaard is? In dat geval (en volgens mij in de meeste gevallen) zijn de evil boeken en tutorials de boosdoeners. Dat is iets wat je heel vaak ziet bij heel veel dingen: men leest een fout boek, leert het fout aan en klaagt vervolgens over systeem B dat de specifieke features van systeem A niet snapt...

Dat is iets waar je volgens mij in het algemeen heel erg voor moet waken, wat je ook leert: zorg dat je de juiste bronnen gebruikt om het te leren.

_{so far deze algemene meditatie}