'SQL is an evolving standard language that closely parallels the evolution of the relational database model. Early implementations were developed in the 1970s and an ANSI committee developed a first standard around 1986. The most recent standard from this group was published in 1992 and most vendors have settled on support for the ANSI92 SQL standard. SQL does not ensure adherence to the relational
46 1 Part I -The Relational Database model but it at least implies it with any database implementation that advertises SQL support.
The structure of the language is based on the relational concept of all data being in table form rather than a flat file. Files have a specific structure and order while tables are unordered sets of items. Languages that address files must explicitly rely on the structure and the sequence of the file itself and thus become inextricably linked to the data structure. One of the most important precepts of the relational model is the separation of the logical and the physical implementation of the database. The SQL language is not directly connected to the underlying storage mechanism and is therefore not affected by the data structure or the storage mechanisms.
Note The first thing to learn about SQL is how to say it! There are two camps, old guys and young bucks, warring over this topic every day. Many in the older camp will pronounce the acronym "sequel," causing great consternation among the young bucks. The youth movement insists that it's pronounced IBM style, one letter at a time, as in "es-queue-et." I'm not getting in the middle of this one. Pronounce it however you feel comfortable.
An important aspect of the SQL language that makes it ideal for working with databases and lends to its continued growth is the declarative nature of the language. The difference between this type of language and the procedural languages that most programmers are familiar with is a crucial point to understanding the structure of SQEs syntax. A procedural language builds a program from a series of step-by-step instructions. Each line of code is designed to tell a program how to perform one of the tasks needed to achieve a goal. A declarative language is focused on what you want to achieve and relies on the language's knowledge of the relational database and its own abilities in deciding how to go about achieving the task.
Consider the task of a music store clerk who relies on a procedural method to respond to customer inquiries. We tell the clerk that we would like to purchase all of the store's Black Flag compact disks. To complete this task, he follows a step-by-step plan for locating the items. First, he goes down one aisle of the store, stopping at each CD to determine if it meets the criteria. If it does, he drops the disk into a basket and moves on to the next bin. He continues this process, up and down each aisle, until he has covered the entire store and reviewed each
Chapter 3-Structured Query Language item. This methodology works fine until the store manager comes in one night and rearranges the layout of the store. Suddenly, our friend finds that his instructions no longer work and he needs to develop a new set of instructions to respond to the changed conditions.
The procedural clerk tires of this exercise and decides to become a declarative agent. A declarative method requires only that we reiterate our request to the clerk. Being smarter now, he has inside structural knowledge of the store and he knows precisely where an item is and how many he has. He also understands the rules by which the manager runs the store. There are no duplicated item storage spots; each item exists in precisely one spot and is addressed by its name, not its storage location.
Was this article helpful?