SQL, which stands for Structured Query Language, is the lingua franca of relational databases - today, no vendor would dare call their database relational if it did not support SQL. "SQL" implies a language that is used to query a database - after all, there is no point putting data into a database unless you can get it out in useful and interesting ways.
The inventor of relational databases, Edgar F .Codd (1923-2003), a mathematician, originally envisaged a database architecture, and a set of operators, that would allow databases to be manipulated the way mathematicians manipulate numbers and symbols: he defined something called "relational algebra" and later "relational calculus". Codd was able to show that certain queries on data, which took a page or two of intricate programming code to implement using the prevalent technology of the time, could be expressed in a single (or a few) short algebraic statements using these operators. All that was needed was a software engine that implemented a translation of these statements into machine operations.
It was soon realized (by others) that most people (even computer programmers) are not mathematicians (and most computer keyboards do not make it convenient to type in esoteric symbols), and that Codd's ideas would be more accessible through a language that more closely resembled ordinary English - the price of accessibility was a very modest verbosity. SQL originally developed at IBM San Jose, was the result.
The word "SQL" is pronounced as its three letters (by the purists), or as "Sequel".
Originally, the SQL definition specified only a means of fetching data from a database; it was gradually extended to ways to change data as well. Together, these comprised a Data Manipulation Language (DML). Still later, SQL was extended to allow definition of a structure of a database (the Data Definition Language or DDL).
The SQL language continues to get refined, with new additions continually being proposed to address a particular problem - e.g., text processing, multimedia, geographical information systems, or time-oriented data. The official standard is that of ISO (the International Standards Organization), which defined revisions to the standard in '89, '92 and '99.
The ISO SQL committee has been justly criticized for inordinate lethargy - doing too little, too late, and codifying standards long after vendors have arrived at their own (proprietary) solutions. In many cases, an aspect of the standard has been introduced so late as to be rendered irrelevant, either because of other technological innovations, or because a major vendor's customers have too much invested in the "old" way of doing things to want to change. Many aspects of the ISO SQL standard are observed more in the breach than in compliance - the most well-known case of this is the latest incarnation, SQL-99, which no major vendor supports.
In any case, today one must accurately refer to SQL as a family of related, vendor-specific dialects that have about 90-95% in common, rather than a single language. Some software packages (notably Microsoft Access) shield you from the gory details of individual dialects: Access translates from its own flavor of SQL to a vendor-specific flavor quite successfully (98 times out of a hundred, though some rare situations exist that will trip it up).
Because this was the last aspect of SQL to get standardized, individual vendors support different ways of doing things. For example, Oracle lets you specify excruciating details such as how much of a table or index is to be cached in memory, at what rate a table will grow and so on, while SQL Server follows a much simpler hands-off approach (you can't specify any of these things- the database engine makes its own decisions).
Data types differ: thus:
Click on this link (numeric data types) to learn about how numbers are stored in Access, and what to avoid.
Dates were among the last data types to be standardized, and different engines support different levels of date arithmetic. Oracle is by far the most primitive, SQL Server is OK, and Access has currently the richest set of date functions.
SQL-92 defined a way of combining multiple tables in a query that used the JOIN operator. Oracle has supported this operator only in the last two years.
The SQL-92 set operators are finally supported in Oracle 9 and later, and in SQL Server 2005.
As we shall see below, the SELECT INTO.. statement becomes the CREATE TABLE..AS... statement in Oracle.
Prior to SQL-99, SQL was best defined as a "mini-language" specialized for the purpose of doing things with relational databases, NOT a computationally complete programming language. That is, it is not possible to specify arbitrary logic in older flavors of SQL, because it does not do branches, loops and subroutines.
That is SQL is considered a declarative language rather than a procedural language. For procedural purposes, SQL was originally intended to be buried with a traditional programming language. (In the case of Access, the "host" language is Visual Basic for Applications or VBA.)
As database vendors beefed up the capabilities of their engines, they found that they needed to provide the ability to store blocks of program code within a database, which could be executed either on demand or automatically when certain things happen, such as adding, deleting or changing records in a table). These blocks of code were called "stored procedures".
Few or no vendors had experts in language implementation, and different customers used different programming languages. So rather than standardizing on a single "standard" programming language, the vendors extended SQL in their own proprietary ways to do branches and the like. This approach, used for more than a decade and a half, was a useful stop gap. However, it had major problems.
The implementations were ad hoc and crippled in many respects. For example, they provided a very limited set of data structures to the programmer, and many algorithms that are trivial to express in a modern programming language were practically impossible to implement in a proprietary SQL dialect. As modern languages such as Java and the .NET languages, continued to evolve rapidly, along with high-quality development and debugging environments, the gap between them and the SQL dialects continued to grow ever wider.
Because proprietary approaches are "bad" in terms of fostering a dependence on a single vendor, ISO eventually defined a standard "procedural" SQL, SQL-99. However, SQL-99 does not deal adequately with the data structures issue, and must be considered dead on arrival. Eventually, Oracle realized that serious programmers are not going to work with a crippled language, and allowed stored procedures to be written in Java. Microsoft, the leader of the non-Java camp, went further, and now allows you (in SQL Server 2005) to write stored procedures in any .NET-supported language, e.g., Visual Basic.NET or C#.
If you understand the SELECT statement thoroughly, you have understood 80% of SQL, because this is the most commonly used statement, as well as the most complex (when you understand its ramifications in terms of all the things it lets you do). The original definition of SQL included only the SELECT statement.
The SELECT statement fetches data from one or more tables. In Access, it can also form the basis of forms and reports.
This topic is important enough to merit a lecture topic by itself. See the SQL Select STatement
This lets you create a new table from a SELECT statement. You use this statement whenever you want to perform a series of complex operations. Rather than try to do everything in one giant statement, you can create temporary tables as you go along.
This statement lets you change the contents of an existing record (or records).
This lets you add one or more records to a table.
This statement lets you delete one or more records- even the entire contents of a table.
In Access, you define a database via the following steps:
You do all this visually. In systems that don't have a visual interface (which was the situation for all high-end systems until the mid 90s), you can do this through prose, in SQL.
Access supports such syntax for the sake for completeness, but to tell you the truth, I've almost never had to use them simply because it is so much faster and so much less error-prone to do things visually. The only time you might need to learn this syntax is if you are a developer who, for example, needs to send a customer a script that creates a set of tables.
The data definition statements of SQL are provided here without explanation.