DZone-10 Easy Steps To A Complete Understanding of SQL

4/9/2016
10EasyStepstoaCompleteUnderstandingofSQLDZoneDatabase
10EasyStepstoaComplete
UnderstandingofSQL
(/users/845183/lukas.eder%40gmail.com.html)by
LukasEder(/users/845183/lukas.eder%40gmail.com.html)
Mar.30,16DatabaseZone(/databasesqlnosqltutorialstoolsnews)
Like(36)
Comment(2)
Save
Tweet
11.64kViews
AsanSQLtrainer(dovisitourtraining,itsgreat
(http://www.jooq.org/training)!)ImwritingSQLeverydayandembracing
SQLwithourcompanysOpenSourcelibraryjOOQ(http://www.jooq.org).
(http://www.jooq.org)
IthusfeelcompelledtobringthebeautyofSQLabitclosertothoseofyou
stillstrugglingwithit.Thefollowingtutorialisdesignedfor:
readerswhohavealreadyworkedwithSQLbutnevercompletely
understoodit
readerswhoknowSQLwellbuthaveneverreallythoughtaboutits
syntax
readerswhowanttoteachSQLtoothers
ThistutorialwillfocusonSELECTstatementsonly.OtherDMLstatements
willbecoveredinanothertutorial.
https://dzone.com/articles/10easystepstoacompleteunderstandingofsql?utm_source=Top%205&utm_medium=email&utm_campaign=top5%20201604 1/22
4/9/2016
Note:ThistutorialwaspreviouslypublishedexclusivelyonTech.Pro
(http://tech.pro)(seeahistoricversionhere
(https://web.archive.org/web/20150312161417/http://tech.pro/tutorial/155
5/10easystepstoacompleteunderstandingofsql)).Unfortunately,
Tech.Prowentoffline.WiththepermissionofTech.Pro,wererepublishing
thiscontentagainonthejOOQblog.
Hereare
10EasyStepstoaCompleteUnderstanding
ofSQL.
1.SQLisDeclarative
Getthisintoyourheadfirst.Declarative.Theonlyparadigmwhereyoujust
declarethenatureoftheresultsthatyouwouldliketoget.Nothowyour
computershallcomputethoseresults.Isntthatwonderful?
1
SELECTfirst_name,last_name
2
FROMemployees
3
WHEREsalary>100000
Easytounderstand.Youdontcarewhereemployeerecordsphysicallycome
from.Youjustwantthosethathaveadecentsalary.
Whatdowelearnfromthis?
Soifthisissosimple,whatstheproblem?Theproblemisthatmostofus
intuitivelythinkintermsofimperativeprogramming
(https://en.wikipedia.org/wiki/Imperative_programming).Asin:"machine,
dothis,andthendothat,butbefore,runacheckandfailifthisandthat".
https://dzone.com/articles/10easystepstoacompleteunderstandingofsql?utm_source=Top%205&utm_medium=email&utm_campaign=top5%20201604
2/22
4/9/2016
dothis,andthendothat,butbefore,runacheckandfailifthisandthat".
Thisincludesstoringtemporaryresultsinvariables,writingloops,iterating,
callingfunctions,etc.etc.
Forgetaboutallthat.Thinkabouthowtodeclarethings.Notabouthowto
tellthemachinetocomputethings.
2.SQLSyntaxisNot"Wellordered"
AcommonsourceofconfusionisthesimplefactthatSQLsyntaxelementsare
notorderedinthewaytheyareexecuted.Thelexicalorderingis:
SELECT[DISTINCT]
FROM
WHERE
GROUPBY
HAVING
UNION
ORDERBY
Forsimplicity,notallSQLclausesarelisted.Thislexicalorderingdiffers
fundamentallyfromthelogicalorder(whichmayagaindifferfromtheorder
ofexecution,dependingontheoptimiserchoices):
FROM
WHERE
GROUPBY
HAVING
SELECT
DISTINCT
UNION
ORDERBY
Therearethreethingstonote:
4/9/2016
Therearethreethingstonote:
1.FROMisthefirstclause,notSELECT.Thefirstthingthathappensis
loadingdatafromthediskintomemory,inordertooperateonsuchdata.
2.SELECTisexecutedaftermostotherclauses.Mostimportantly,after
FROMandGROUPBY.Thisisimportanttounderstandwhenyouthink
youcanreferencestuffthatyoudeclareintheSELECTclausefromthe
WHEREclause.Thefollowingisnotpossible:
1
SELECTA.x+A.yASz
2
FROMA
3
WHEREz=10zisnotavailablehere!
Ifyouwantedtoreuse z ,youhavetwooptions.Eitherrepeatthe
expression:
1
SELECTA.x+A.yASz
2
FROMA
3
WHERE(A.x+A.y)=10
oryouresorttoderivedtables,commontableexpressions,orviewsto
avoidcoderepetition.Seeexamplesfurtherdown.
3.UNIONisplacedbeforeORDERBYinbothlexicalandlogicalordering.
4/9/2016
3.UNIONisplacedbeforeORDERBYinbothlexicalandlogicalordering.
ManypeoplethinkthateachUNIONsubselectcanbeordered,but
accordingtotheSQLstandardandmostSQLdialects,thatisnottrue.
Whilesomedialectsallowfororderingsubqueriesorderivedtables,
thereisnoguaranteethatsuchorderingwillberetainedafteraUNION
operation
Note,notalldatabasesimplementthingsthesameway.Rulenumber2,for
instance,doesnotapplyexactlyintheabovewaytoMySQL,PostgreSQL,and
SQLite.
AlwaysrememberboththelexicalorderandthelogicalorderofSQLclauses
toavoidverycommonmistakes.Ifyouunderstandthatdistinction,itwill
becomeveryobviouswhysomethingsworkandothersdont.
Ofcourse,itwouldhavebeenniceifthelanguagewasdesignedinawaythat
thelexicalorderactuallyreflectedthelogicalorder,asitisimplementedin
MicrosoftsLINQ(http://msdn.microsoft.com/en
us/library/vstudio/bb397926.aspx).
3.SQLisAboutTableReferences
Becauseofthedifferencebetweenlexicalorderingandlogicalordering,most
beginnersareprobablytrickedintothinkingthatcolumnvaluesarethefirst
classcitizensinSQL.Theyarenot.Themostimportantthingsaretable
references.
TheSQLstandard
(http://www.andrew.cmu.edu/user/shadow/sql/sql1992.txt)definesthe
FROMclauseassuch:
1
<fromclause>::=
2
FROM<tablereference>
3
4/9/2016
[{<comma><tablereference>}...]
TheoutputoftheFROMclauseisacombinedtablereferenceofthe
combineddegreeofalltablereferences.Letsdigestthis,slowly.
1
FROMa,b
Theaboveproducesacombinedtablereferenceofthedegreeof a +the
degreeof b .If a has3columnsand b has5columns,thentheoutputtable
willhave8( 3+5 )columns.
Therecordscontainedinthiscombinedtablereferencearethoseofthecross
product/cartesianproductof axb .Inotherwords,eachrecordof a is
pairedwitheachrecordof b .If a has3recordsand b has5records,thenthe
abovecombinedtablereferencewillproduce15records( 3x5 ).
Thisoutputisfed/pipedintotheGROUPBYclause(afterfilteringin
theWHEREclause),whereitistransformedintoanewoutput.Welldeal
withthatlateron.
Ifwerelookingatthesethingsfromarelationalalgebra
(http://en.wikipedia.org/wiki/Relational_algebra)/settheory
(http://en.wikipedia.org/wiki/Set_theory)perspective,aSQLtableisa
relationorasetoftuples.AndeachSQLclausewilltransformoneorseveral
relationsinordertoproducenewrelations.
Alwaysthinkintermsoftablereferencestounderstandhowdatais
pipelinedthroughyourSQLclauses.
4.SQLTableReferencesCanBeRatherPowerful
Atablereferenceissomethingratherpowerful.Asimpleexampleoftheir
Atablereferenceissomethingratherpowerful.Asimpleexampleoftheir
poweristheJOINkeyword,whichisactuallynotpartoftheSELECT
statement,butpartofaspecialtablereference.Thejoinedtable,asdefined
intheSQLstandard
(http://www.andrew.cmu.edu/user/shadow/sql/sql1992.txt)(simplified):
4/9/2016
1
<tablereference>::=
2
<tablename>
3
|<derivedtable>
4
|<joinedtable>
Ifwetakeagaintheexamplefrombefore:
1
FROMa,b
canbeajoinedtableassuch:
1
a1JOINa2ONa1.id=a2.id
Expandingthisintothepreviousexpression,wedget:
1
FROMa1JOINa2ONa1.id=a2.id,b
Whileitisdiscouragedtocombinethecommaseparatedlistoftable
4/9/2016
Whileitisdiscouragedtocombinethecommaseparatedlistoftable
referencessyntaxwiththejoinedtablesyntax,youcanmostcertainlydothis.
Theresulting,combinedtablereferencewillnowhaveadegreeof a1+a2+b .
Derivedtablesareevenmorepowerfulthanjoinedtables.Wellgettothat.
Always,alwaysthinkintermsoftablereferences.Notonlyisthisimportantto
understandhowdataispipelinedthroughyourSQLclauses(seeprevious
section),itwillalsohelpyouunderstandhowcomplextablereferencesare
constructed.
And,importantly,understandthatJOINisakeywordforconstructingjoined
tables.NotapartoftheSELECTstatement.Somedatabasesallowforusing
JOINinINSERT,UPDATE,DELETE
5.SQLJOINTablesShouldBeUsedRatherThan
CommaseparatedTables
Before,weveseenthisclause:
1
FROMa,b
AdvancedSQLdeveloperswillprobablytellyouthatitisdiscouragedtouse
thecommaseparatedlistatall,andalwaysfullyexpressyourJOINs.Thiswill
helpyouimprovereadabilityofyourSQLstatement,andthusprevent
mistakes.
OneverycommonmistakeistoforgetaJOINpredicatesomewhere.Think
aboutthefollowing:
1
FROMa,b,c,d,e,f,g,h
2
WHEREa.a1=b.bx
4/9/2016
3
ANDa.a2=c.c1
4
ANDd.d1=b.bc
5
etc...
Thejointablesyntaxisboth
Safer,asyoucanplacejoinpredicatesclosetothejoinedtables,thus
preventingmistakes.
Moreexpressive,asyoucandistinguishbetweenOUTERJOIN,INNER
JOIN,etc.
AlwaysuseJOIN.NeverusecommaseparatedtablereferencesinyourFROM
clauses.
6.SQLsDifferentJOINOperations
JOINoperationsessentiallycomewithfiveflavours:
EQUIJOIN
SEMIJOIN
ANTIJOIN
CROSSJOIN
DIVISION
Thesetermsarecommonlyusedinrelationalalgebra
(https://en.wikipedia.org/wiki/Relational_algebra).SQLusesdifferentterms
9/22
fortheaboveconcepts,iftheyexistatall.Letshaveacloserlook:
4/9/2016
fortheaboveconcepts,iftheyexistatall.Letshaveacloserlook:
EQUIJOIN
ThisisthemostcommonJOINoperation.Ithastwosubflavours:
INNERJOIN(orjustJOIN)
OUTERJOIN(furthersubflavouredasLEFT,RIGHT,FULLOUTER
JOIN)
Thedifferenceisbestexplainedbyexample:
1
Thistablereferencecontainsauthorsandtheirbooks.
2
Thereisonerecordforeachbookanditsauthor.
3
authorswithoutbooksareNOTincluded
4
authorJOINbookONauthor.id=book.author_id
5
6
Thistablereferencecontainsauthorsandtheirbooks
7
Thereisonerecordforeachbookanditsauthor.
8
...ORthereisan"empty"recordforauthorswithoutbooks
9
("empty"meaningthatallbookcolumnsareNULL)
10
authorLEFTOUTERJOINbookONauthor.id=book.author_id
4/9/2016
SEMIJOIN
ThisrelationalconceptcanbeexpressedintwowaysinSQL:UsinganIN
predicate,orusinganEXISTSpredicate
(http://blog.jooq.org/2015/10/13/semijoinandantijoinshouldhaveits
ownsyntaxinsql/).Semimeanshalfinlatin.Thistypeofjoinisusedto
joinonlyhalfofatablereference.Whatdoesthatmean?Consideragainthe
abovejoiningofauthorandbook.Letsimaginethatwedontwant
author/bookcombinations,butjustthoseauthorswhoactuallyalsohave
books.Thenwecanwrite:
1
UsingIN
2
FROMauthor
3
WHEREauthor.idIN(SELECTbook.author_idFROMbook)
4
5
UsingEXISTS
6
FROMauthor
7
WHEREEXISTS(SELECT1FROMbookWHEREbook.author_id=author.id)
11/22
4/9/2016
WHEREEXISTS(SELECT1FROMbookWHEREbook.author_id=author.id)
WhilethereisnogeneralruleastowhetheryoushouldpreferINorEXISTS,
thesethingscanbesaid:
INpredicatestendtobemorereadablethanEXISTSpredicates
EXISTSpredicatestendtobemoreexpressivethanINpredicates(i.e.it
iseasiertoexpressverycomplexSEMIJOIN)
Thereisnoformaldifferenceinperformance.Theremay,however,bea
hugeperformancedifferenceonsomedatabases
(http://explainextended.com/2009/09/18/notinvsnotexistsvsleft
joinisnullmysql/).
BecauseINNERJOINalsoproducesonlythoseauthorsthatactuallyhave
books,manybeginnersmaythinkthattheycanthenremoveduplicatesusing
DISTINCT.TheythinktheycanexpressaSEMIJOINlikethis:
1
Findonlythoseauthorswhoalsohavebooks
2
SELECTDISTINCTfirst_name,last_name
3
FROMauthor
4
JOINbookONauthor.id=book.author_id
4/9/2016
Thisisverybadpracticefortworeasons:
Itisveryslow,asthedatabasehastoloadalotofdataintomemory,just
toremoveduplicatesagain.
Itisnotentirelycorrect,evenifitproducesthecorrectresultinthis
simpleexample.ButassoonasyouJOINmoretablereferences,youwill
haveaveryhardtimecorrectlyremovingduplicatesfromyourresults.
SomemoreinformationaboutabuseofDISTINCTcanbeseeninthisblog
post(http://blog.jooq.org/2013/07/30/10commonmistakesjava
developersmakewhenwritingsql/).
ANTIJOIN
ThisrelationalconceptisjusttheoppositeofaSEMIJOIN.Youcanproduce
itsimplybyaddingaNOTkeywordtotheINorEXISTSpredicates.An
example,wherewellselectthoseauthorswhodonothaveanybooks:
1
UsingIN
2
FROMauthor
3
WHEREauthor.idNOTIN(SELECTbook.author_idFROMbook)
4
5
UsingEXISTS
6
FROMauthor
7
WHERENOTEXISTS(SELECT1FROMbookWHEREbook.author_id=author.id)
4/9/2016
Thesameruleswithrespecttoperformance,readability,expressivityapply.
However,thereisasmallcaveatwithrespecttoNULLswhenusingNOTIN,
whichisabitoutofscopeforthistutorial
(http://blog.jooq.org/2012/01/27/sqlincompatibilitiesnotinandnull
values/).
CROSSJOIN
Thisproducesacrossproductofthetwojoinedtablereferences,combining
everyrecordofthefirsttablereferencewitheveryrecordofthesecondtable
reference.Wehaveseenbefore,thatthiscanbeachievedwithcomma
separatedtablereferencesintheFROMclause.Intherarecaseswherethisis
reallydesired,youcanalsowriteaCROSSJOINexplicitly,inmostSQL
dialects:
1
Combineeveryauthorwitheverybook
2
authorCROSSJOINbook
DIVISION
Therelationaldivisionisreallyabeastofitsownbreed.Inshort,ifJOINis
multiplication,divisionistheinverseofJOIN.Relationaldivisionsarevery
toughtoexpressinSQL.Asthisisabeginnerstutorial,explainingitisoutof
(/)
scope.Forthebraveamongyou,readonaboutithere
(http://blog.jooq.org/2012/03/30/advancedsqlrelationaldivisionin
jooq/),here(http://en.wikipedia.org/wiki/Relational_algebra#Division),and
here(https://www.simpletalk.com/sql/tsqlprogramming/dividedwe
standthesqlofrelationaldivision/).
14/22
ThanksforvisitingDZonetoday,(/users/1114339/ssmsam12345.html)
/DatabaseZone(/databasesqlnosql
tutorialstoolsnews)
4/9/2016
standthesqlofrelationaldivision/).
ThanksforvisitingDZonetoday,(/users/1114339/ssmsam12345.html)
(/users/1114339/ssmsam12345.html)
Sampat(/users/1114339/ssmsam12345.html)
Alot.Again,letshammerthisintoourheads.SQLisabouttablereferences.
Joinedtablesarequitesophisticatedtablereferences.Butthereisadifference
inrelationalspeakandSQLspeak.Notallrelationaljoinoperationsarealso
REFCARDZ(/REFCARDZ) GUIDES(/GUIDES) ZONES(/PORTALS) |
formalSQLjoinoperations.Withabitofpracticeandknowledgeabout
relationaltheory,youwillalwaysbeabletochoosetherighttypeofrelational
JOINandbeabletotranslateittothecorrectSQL.
7.SQLsDerivedTablesAreLikeTableVariables
Before,wevelearnedthatSQLisadeclarativelanguage,andassuch,
variablesdonothaveaplace(theydoinsomeSQLdialects,though).Butyou
canwritesomethinglikevariables.Andthosebeastsarecalledderivedtables.
Aderivedtableisnothingbutasubquerywrappedinparentheses.
1
Aderivedtable
2
FROM(SELECT*FROMauthor)
NotethatsomeSQLdialectsrequirederivedtablestohaveacorrelation
name(alsoknownasalias).
1
Aderivedtablewithanalias
2
FROM(SELECT*FROMauthor)a
Derivedtablesareawesomewhenyouwanttocircumventtheproblems
causedbythelogicalorderingofSQLclauses.Forinstance,ifyouwantto
reuseacolumnexpressioninboththeSELECTandtheWHEREclause,just
15/22
4/9/2016
reuseacolumnexpressioninboththeSELECTandtheWHEREclause,just
write(Oracledialect):
1
Getauthors'firstandlastnames,andtheirageindays
2
SELECTfirst_name,last_name,age
3
FROM(
4
SELECTfirst_name,last_name,current_datedate_of_birthage
5
FROMauthor
6
)
7
Iftheageisgreaterthan10000days
8
WHEREage>10000
Notethatsomedatabases,andtheSQL:1999standardhavetakenderived
tablestothenextlevel,introducingcommontableexpressions.Thiswillallow
youtoreusethesamederivedtableseveraltimeswithinasingleSQLSELECT
statement.Theabovequerywouldthentranslatetothe(almost)equivalent:
1
WITHaAS(
4/9/2016
WITHaAS(
2
SELECTfirst_name,last_name,current_datedate_of_birthage
3
FROMauthor
4
)
5
SELECT*
6
FROMa
7
WHEREage>10000
Obviously,youcouldalsoexternaliseaintoastandaloneviewforeven
broaderreuseofcommonSQLsubselects.Readmoreaboutviewshere
(http://en.wikipedia.org/wiki/View_%28SQL%29).
Again,again,again.SQLismostlyabouttablereferences,notcolumns.Make
useofthem.Dontbeafraidofwritingderivedtablesorothercomplextable
references.
8.SQLGROUPBYTransformsPreviousTable
References
LetsreconsiderourpreviousFROMclause:
1
17/22
4/9/2016
1
FROMa,b
Andnow,letsapplyaGROUPBYclausetotheabovecombinedtable
reference
1
GROUPBYA.x,A.y,B.z
Theaboveproducesanewtablereferencewithonlythreeremainingcolumns
(!).Letsdigestthisagain.IfyouapplyGROUPBY,thenyoureducethe
numberofavailablecolumnsinallsubsequentlogicalclausesincluding
SELECT.Thisisthesyntacticalreasonwhyyoucanonlyreferencecolumns
fromtheGROUPBYclauseintheSELECTclause.
Notethatothercolumnsmaystillbeavailableasargumentsofaggregate
functions:
1
SELECTA.x,A.y,SUM(A.z)
2
FROMA
3
GROUPBYA.x,A.y
NotethatMySQL,unfortunately,doesntadheretothisstandard
(http://blog.jooq.org/2012/08/05/mysqlbadidea384/),causing
nothingbutconfusion.DontfallforMySQLstricks.GROUPBY
transformstablereferences.Youcanthusonlyreferencecolumnsalso
referencedintheGROUPBYclause.
4/9/2016
GROUPBY,again,operatesontablereferences,transformingthemintoanew
form.
9.SQLSELECTisCalledProjectioninRelational
Algebra
Ipersonallylikethetermprojection,asitisusedinrelationalalgebra.Once
youvegeneratedyourtablereference,filteredit,transformedit,youcanstep
toprojectingittoanotherform.TheSELECTclauseislikeaprojector.Atable
functionmakinguseofarowvalueexpressiontotransformeachrecordfrom
thepreviouslyconstructedtablereferenceintothefinaloutcome.
WithintheSELECTclause,youcanfinallyoperateoncolumns,creating
complexcolumnexpressionsaspartsoftherecord/row.
Therearealotofspecialruleswithrespecttothenatureofavailable
expressions,functions,etc.Mostimportantly,youshouldrememberthese:
1.Youcanonlyusecolumnreferencesthatcanbeproducedfromthe
outputtablereference
2.IfyouhaveaGROUPBYclause,youmayonlyreferencecolumnsfrom
thatclause,oraggregatefunctions.
3.Youcanusewindowfunctionsinsteadofaggregatefunctions,whenyou
donthaveaGROUPBYclause.
4.IfyoudonthaveaGROUPBYclause,youmustnotcombineaggregate
functionswithnonaggregatefunctions.
5.Therearesomeruleswithrespecttowrappingregularfunctionsin
aggregatefunctionsandviceversa.
6.Thereare
Well,therearelotsofcomplexrules.Theycouldfillyetanothertutorial.For
instance,thereasonwhyyoucannotcombineaggregatefunctionswithnon
aggregatefunctionsintheprojectionofaSELECTstatementwithoutGROUP
BYclause(rulenumber4)isthis:
4/9/2016
BYclause(rulenumber4)isthis:
1.Itdoesntmakesense.Intuitively.
2.Ifintuitiondoesnthelp(ithardlydoes,withaSQLbeginner),then
syntaxrulesdo.SQL:1999introducedGROUPINGSETS,andSQL:2003
introducedemptygroupingsets:GROUPBY().Wheneveranaggregate
functionispresent,andthereisnoexplicitGROUPBYclause,an
implicit,emptyGROUPINGSETisapplied(rulenumber2).Hence,the
originalrulesaboutlogicalorderingarentexactlytrueanymore,andthe
projection(SELECT)influencestheoutcomeofalogicallypreceding,yet
lexicallysucceedingclause(GROUPBY).
Confused?Yes.Metoo.Letsgetbacktosimplerthings.
TheSELECTclausemaybeoneofthemostcomplexclausesinSQL,evenifit
appearssosimple.Allotherclausesjustpipetablereferencesfromoneto
another.TheSELECTclausemessesupthebeautyofthesetablereferences,
bycompletelytransformingthem,applyingsomerulestothemretroactively.
InordertounderstandSQL,itisimportanttounderstandeverythingelse
first,beforetryingtotackleSELECT.EvenifSELECTisthefirstclausein
lexicalordering,itshouldbethelast.
10.SQLDISTINCT,UNION,ORDERBY,andOFFSET
AreSimpleAgain
AfterthecomplicatedSELECT,wecangetbacktosimplethingsagain:
Setoperations(DISTINCTandUNION)
Orderingoperations(ORDERBY,OFFSET..FETCH)
Setoperations
Setoperationsoperateonsets,whichareactuallynothingotherthan
tables.Well,almost.Conceptually,theyreeasytounderstand.
DISTINCTremovesduplicatesaftertheprojection.
4/9/2016
UNIONconcatenatestwosubselectsandremovesduplicates
UNIONALLconcatenatestwosubselectsretainingduplicates
EXCEPTremovesrecordsfromthefirstsubselectthatarealsocontained
inthesecondsubselect(andthenremovesduplicates)
INTERSECTretainsonlyrecordscontainedinbothsubselects(andthen
removesduplicates)
Allofthisremovingduplicatesisusuallynonsense.Mostoften,youshould
justuseUNIONALL,whenyouwanttoconcatenatesubselects.
Orderingoperations
Orderingisnotarelationalfeature.ItisaSQLonlyfeature.Itisappliedatthe
veryendofbothlexicalorderingandlogicalorderingofyourSQLstatement.
UsingORDERBYandOFFSET..FETCHistheonlywaytoguaranteethat
recordscanbeaccessedbyindexinareliableway.Allotherorderingisalways
arbitraryandrandom,evenifitmayappeartobereproducible.
OFFSET..FETCHisonlyonesyntaxvariant.OthervariantsincludeMySQLs
andPostgreSQLsLIMIT..OFFSET,orSQLServersandSybasesTOP..
STARTAT.AgoodoverviewofvariouswaystoimplementOFFSET..FETCH
canbeseenhere(http://www.jooq.org/doc/3.1/manual/sqlbuilding/sql
statements/selectstatement/limitclause/).
LetsGettoWork
Aswitheverylanguage,SQLtakesalotofpracticetomaster.Theabove10
simplestepswillhelpyoumakemoresenseoftheeverydaySQLthatyoure
writing.Ontheotherhand,itisalsogoodtolearnfromcommonmistakes.
ThefollowingtwoarticleslistlotsofcommonmistakesJava(andother)
developersmakewhenwritingSQL:
Topics: SQL, SQLFUNCTIONS, DATABASEABSTRACTIONLAYER

PublishedatDZonewithpermissionofLukasEder,DZoneMVB.
(http://blog.jooq.org/2016/03/17/10easystepstoacompleteunderstandingofsql)
OpinionsexpressedbyDZonecontributorsaretheirown.

DZone-10 Easy Steps To A Complete Understanding of SQL

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DZone-10 Easy Steps To A Complete Understanding of SQL

Uploaded by

Copyright:

Available Formats

4/9/2016

Topics: SQL, SQLFUNCTIONS, DATABASEABSTRACTIONLAYER

You might also like