Abstract
This chapter appraises the nature of programming in structured query language (SQL). Certain guidelines are offered to help programming SQL, namely—procedural code is replaced with declarative code, proprietary code is replaced with Standard SQL. DDL and DML are used together for a solution, and the solution shows a pattern that can be useful for similar problems. But perhaps the hardest thing to learn is thinking in sets. Sets can be defined two ways. Listing the elements; in math this is done with a pair of curvy brackets and a comma-separated list. This method is fine for small sets, and technically that is what a table is.The other method is to give a characteristic function that takes a value and returns a 1 or TRUE if the value is in the set and a zero or FALSE if it is not an element. That is what constraints do in SQL. Both these methods are used to define a table properly. A properly defined table is made up of one and only one kind of entity. The big leap in SQL programming is thinking in sets and not in process steps that handle one unit of data at a time. Phrases like “for the next x do…” poison the mental model of the problem. Programmers coming from procedural languages think in terms of actions. They add numbers, while declarative programmers look at a total.
Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callMore From: Joe Celko's Thinking in Sets: Auxiliary, Temporal, and Virtual Tables in SQL
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
