Structured Query Language is, helpfully, a declarative language and therefore it’s incredibly simple to understand. For example, you want to select a column of data from a table? That’s exactly what you do:
You want to filter the data to only where the column equals a value? No problem:
WHERE column = value
It couldn’t be simpler. Obviously, there are nuances and it can get much more complex than just using one table, but the underlying premise is simply that of a language which anyone can grasp with little to no SQL Server training and immediately be able to write code against a database server.
However, this is not the case in reality. Even from the most basic starting blocks, are you aware that SQL, the language, is different in syntax to t-SQL? The latter be Transact-SQL, the variant of SQL created by Microsoft and containing differences from the ANSI standard, meaning it won’t natively run on other SQL based systems?
Beyond that, there are different constructs which can have drastic performance impacts on your system which mean that the language’s declarative nature actually work heavily against it. SQL itself contains constructs that look sensible yet are performance heavy alongside shortcuts which, whilst far from simple to wrap your head around, can make incredibly short work of otherwise onerous tasks.
All of the above comes into play well before we even consider the internals of the software and therefore exactly how the t-SQL is being executed, whether this will be efficient or not based on how it has been interpreted irrespective of the nice, neat, easy to understand way in which we, the user, wrote the code.
Correct SQL Server Training can be invaluable when both starting off on your SQL path and for the seasoned professional in order to ensure that your code is not only declarative but that it’s the best code for the task in hand.