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 . 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. 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. 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