The Language of SQL- P38 pdf

Looking Ahead
In this chapter, we’ve seen that the use of parameters can add a great deal of
flexibility to the process of retrieving data. For example, parameters allow you to
generalize SQL statements so that values for selection criteria can be specified at
the time the statement is executed. You’ve also learned the basics of how to create
and modify stored procedures. Finally, we expla ined some of the differences
between stored procedures and user-defined functions.
Although the examples in the present chapter were focused on data retrieval,
stored procedures and functions are also quite useful in applying data updates.
Our next chapter, ‘‘Mod ifying Data,’’ will take us completely out of the realm of
data retrieval and move us squarely into issues surrounding the need to update
data. The business of maintaining data doesn’t present the same analytic possi-
bilities as data retrieval, but it is a necessary task for any enterprise. Fortunately,
most of the techniques you’ve learned with the
SELECT statement apply equally
to the modification processes to be discussed in the next chapter.
Looking Ahead 171
This page intentionally left blank
chapter 17
Modifying Data
Keywords Introduced: INSERT INTO,
VALUES, DELETE, TRUNCATE TABLE , UPDATE
Having exhausted our discussion of retrieving data from databases, we will now
move on to the topic of how to modify data. There are three basic scenarios as to
how data can be modified:
■ Inserting new rows into a table
■ Deleting rows from a table
■ Updating existing data in specific rows and columns in a table
As you may surmise, inserting and deleting rows is relatively straightforward.
Updating existing data, however, is a more complex endeavor. We’ll begin with
the insert and delete functions and then conclude with updates.

Modification Strategies
The mechanics of modifying data are fairly straightforward. However, the nature
of the process means that this is an area fraught with danger. Being human,
mistakes can be made. With a single command, you can easily delete thousands
of rows in error. Or you can apply numerous updates that may be difficult to
retract.
As a practical matter, there are various str ategies that can be employed to help
prevent catastrophic blunders. For example, when deleting rows from a table,
173
you can employ a soft delete technique, which means that instead of actually
deleting rows, you can denote a special column in a table that marks each row as
either active or inactive. Rather than deleting a row, you merely mark a row as
being inactive. That way, if a delete is done in error, you can easily reverse it by
changing the value of the active/inactive column.
A similar technique can be utilized when doing inserts. When adding a row, you
can mark in a special column the exact date and time of the insert. If it is later
determined that the row was added in error, you can find all rows added in a
specified time range and have them deleted.
The problem is more complex when it comes to updating data. Generally, it’s
advisable to maintain a separate table that holds data on intended update trans-
actions. If any kind of error is made, you can go back to the transaction table to
look up the before-and-after values for data that was modified and use that to
reverse any earlier mistakes.
The above mentioned strategies are just a few of the many approaches that can be
taken. This is a topic that is well beyond the scope of this book. Just be sure that
you are very cautious when updating data. Unlike many user-friendly desktop
applications, there is no undo command in SQL.
Inserting Data
SQL provides an INSERT keyword to add data into a table. There are two basic
ways in which an

INSERT can be done:
■ Insert specific data that is listed in an INSERT statement
■ Insert data that is obtained from a SELECT statement
Let’s start with an example that shows how to insert data, where the data values
are specified in the
INSERT statement. Let’s assume that we have a Customers
table with this data already in it:
CustomerID FirstName LastName State
1 William Smith IL
2 Natalie Lopez WI
3 Brenda Harper NV
Chapter 17
■
Modifying Data174
Let’s also assume that the first column, CustomerID, is the primary key for the
table. Back in Chapters 1 and 2, we talked about the fact that primary keys
enforce the requirement that each row in a table should be uniquely identifiable.
We also mentioned that it is often the case that primary key columns are speci-
fied as auto-increment columns. This means that they are automatically assigned
a number as a row is added to the table.
Assuming that the CustomerID column is defined as an auto-increment column,
this means that when we add a row to the Customers table, we don’t specify
a value for the CustomerID column. It will be automatically determined as a
row is added to the table. We only need to specify values for the other three
columns.
Let’s proceed with an attempt to add two new customers to the table: Virginia
Jones from Ohio and Clark Woodland from California.
This statement performs the insert:
INSERT INTO Customers
(FirstName, LastName, State)

VALUES
('Virginia', 'Jones', 'OH'),
('Clark', 'Woodland', 'CA')
After the insert, the table contains:
CustomerID FirstName LastName State
1 William Smith IL
2 Natalie Lopez WI
3 Brenda Harper NV
4 Virginia Jones OH
5 Clark Woodland CA
A few words of explanation are in order. First, notice that the VALUES keyword
is used as a prefix to lists of values to be inserted into the table. The statement
lists each row of data in a separate set of parentheses. Virginia Jones of Ohio was
in one set of parentheses; Clark Woodland was in another set. The two sets were
separated by a comma. If we needed to only add one row, then just one set of
parentheses would be needed.
Inserting Data 175