The Language of SQL- P40 ppsx

A more common example of an UPDATE involves situations where you update data in one table based on data in another table.. Let’s say we have this Customers table: This CustomerTransactio

essential Without the WHERE clause, every row in the table would have been

changed to Bill Smythe

Correlated Subquery Updates

The previous UPDATE example is easy enough but not entirely realistic

A more common example of an UPDATE involves situations where you

update data in one table based on data in another table Let’s say we have this

Customers table:

This CustomerTransactions table has the recent changes for existing customers:

TransactionID CustomerID State Zip

The Customers table is considered to be the main source of data for customers

In order to accomplish an update of the Customers table from the

CustomerTransactions table, we’re going to need to use the correlated subquery

technique discussed in Chapter 14 The correlated subquery is needed because

theUPDATEstatement can only specify a single table to update We can’t merely

join multiple tables together and have it work We’ll need to use a correlated

subquery after theSETkeyword to indicate where the data comes from

The following statement can be utilized to update the State and Zip columns in

the Customers table from the transactions in the CustomerTransactions table

Since this statement is fairly complex, we’ve inserted a few blank lines so we can

subsequently discuss the four sections of the statement

UPDATE Customers

SET Customers.State =

(SELECT CustomerTransactions.State

FROM CustomerTransactions

WHERE CustomerTransactions.CustomerID = Customers.CustomerID),

Customers.Zip =

(SELECT CustomerTransactions.Zip

FROM CustomerTransactions

WHERE CustomerTransactions.CustomerID = Customers.CustomerID)

WHERE EXISTS

(SELECT *

FROM CustomerTransactions

WHERE CustomerTransactions.CustomerID = Customers.CustomerID)

After executing thisUPDATE, the Customers table contains:

Let’s analyze this UPDATE statement in some detail The first section of the statement, consisting of the first line, indicates that the update is to be done on the Customers table

The second section of the statement specifies how the State column is to be updated The update is based on this correlated subquery:

SELECT CustomerTransactions.State

FROM CustomerTransactions

WHERE CustomerTransactions.CustomerID =

Customers.CustomerID

We can tell that this is a correlated subquery because it would error if we attempted to execute thisSELECTon its own The subquery is taking data from

Chapter 17 ■ Modifying Data

182

the CustomerTransactions table and matching between the two tables by

CustomerID

The third section of the statement is identical to the second section, except that

these lines are concerned with updates to the Zip column Also notice that the

SET keyword only needed to be specified once, in the second section It isn’t

needed in the third section

The final section has logic in aWHERE clause associated with the selection logic

for the entire UPDATE statement The EXISTS operator is used along with

another correlated subquery to determine whether rows exist in the

CustomerTransactions table for each CustomerID in the Customers table

Without thisWHERE clause, the update would incorrectly change the State and

Zip columns for customers 3 and 4 to NULL values because these customers do

not have rows in the CustomerTransactions table The correlated subquery in

thisWHEREclause makes certain that we only apply updates for customers who

do, in fact, have data in the CustomerTransactions table

As can be inferred, the subject of using correlated subqueries for updates is quite

complex As such, the topic is generally beyond the scope of this book However,

we’ve included this example if only to give an idea of some of the complexities

that are involved in data updates Additionally, it should be noted that correlated

subqueries are similarly useful with deletes

Looking Ahead

This chapter presented an overview of the various methods of updating data The

mechanics of executing simple inserts, deletes, and updates are relatively

straightforward However, the correlated subquery technique, which is often

necessary for real-world updates and deletes, is not for the faint of heart

Additionally, the entire notion of applying updates to data is a demanding

exercise With the power of SQL’s ability to update thousands of rows of data

with a single command comes an admonition to be cautious when performing

any type of update Procedures for reversing any updates should be carefully

planned out before any data modifications are applied

Now that we’ve talked about modifying the data in tables, we next progress to a

discussion of the tables themselves In the next chapter, ‘‘Maintaining Tables,’’

we’re going to look at the mechanics of creating tables along with all the attri-butes needed to properly hold the data in those tables As such, we’ll be revisiting some of the topics touched upon in Chapter 1, such as primary and foreign keys,

in greater detail Up until now, we’ve assumed that tables are simply available for our use After this examination, you’ll have a much better idea of how to create the tables that will hold your data

Chapter 17 ■ Modifying Data

184

Maintaining Tables

Keywords Introduced: CREATE TABLE ,

With this chapter, we change our focus from data retrieval and modification to design Up until now, we’ve assumed that tables simply exist and are available to

us However, in the normal course of events, you need to create tables before the data in them can be accessed We now turn to the question of how to create and maintain tables

We’ve previously touched on a few of the topics we’ll be addressing, such as primary and foreign keys, but we now want to delve into these areas in greater detail and also bring in the related topic of table indexes

Data Definition Language

Way back in Chapter 1, we mentioned that there are three main components of the SQL language: DML (Data Manipulation Language), DDL (Data Definition Language), and DCL (Data Control Language) Up until now, most of what we’ve talked about has been DML DML statements allow you to manipulate data in relational databases by retrieval, insertion, deletion, or update This is handled by theSELECT,INSERT,DELETE, andUPDATEstatements

Although our focus has been on DML, we have already seen a few instances of DDL (Data Definition Language) TheCREATE VIEWandCREATE PROCEDURE

statements are DDL, and so are the relatedALTER andDROP versions of those statements

185