Hướng dẫn học Microsoft SQL Server 2008 part 39 doc

Nielsen c14.tex V4 - 07/21/2009 12:49pm Page 342 Part II Manipulating Data with Select Unchecked data To understand the need for the WITH CHECK OPTION, it’s important to first understand how views function without the CHECK OPTION. The following view will generate a list of tours for the Cape Hatteras base camp: USE CHA2; CREATE VIEW dbo.vCapeHatterasTour AS SELECT TourName, BaseCampID FROM dbo.Tour WHERE BaseCampID = 2; go SELECT TourName, BaseCampID FROM dbo.vCapeHatterasTour; TourName BaseCampID Outer Banks Lighthouses 2 If the Ashville base camp adds a Blue Ridge Parkway Hike tour and inserts it through the view without the CHECK OPTION,theINSERT is permitted: INSERT dbo.vCapeHatterasTour (TourName, BaseCampID) VALUES (’Blue Ridge Parkway Hike’, 1); (1 row(s) affected) The INSERT worked, and the new row is in the database, but the row is not visible through the view because the WHERE clause of the view filters out the inserted row. This phenomenon is called disappear- ing rows: SELECT TourName, BaseCampID FROM dbo.vCapeHatterasTour; TourName BaseCampID Outer Banks Lighthouses 2 If the purpose of the view were to give users at the Cape access to their tours alone, then the view failed. Although they can see only the Cape’s tours, they successfully modified another base camp’s tours. The WITH CHECK OPTION would have prevented this fault. Protecting the data A view with a WHERE clause and the WITH CHECK OPTION can protect the data from undesired inserts and updates. The following code will back out the previous INSERT and redo the same scenario, but this time the view will include the WITH CHECK OPTION: DELETE dbo.vCapeHatterasTour WHERE TourName = ‘Blue Ridge Parkway Hike’; 342 www.getcoolebook.com Nielsen c14.tex V4 - 07/21/2009 12:49pm Page 343 Projecting Data Through Views 14 go ALTER VIEW dbo.vCapeHatterasTour AS SELECT TourName, BaseCampID FROM dbo.Tour WHERE BaseCampID = 2 WITH CHECK OPTION; go INSERT dbo.vCapeHatterasTour (TourName, BaseCampID) VALUES (’Blue Ridge Parkway Hike’, 1); Server: Msg 550, Level 16, State 1, Line 1 The attempted insert or update failed because the target view either specifies WITH CHECK OPTION or spans a view that specifies WITH CHECK OPTION and one or more rows resulting from the operation did not qualify under the CHECK OPTION constraint. The statement has been terminated. This time the INSERT failed and the error message attributed the cause to the WITH CHECK OPTION in the view, which is exactly the effect desired. Some developers employ views and the WITH CHECK OPTION as a way of providing row-level security — a technique called horizontally positioned views.Asinthebasecampviewexample,they create a view for each department, or each sales branch, and then give users security permission to the view that pertains to them. While this method does achieve row-level security, it also has a high maintenance cost. For the application, row-level security can be designed using user-access tables and stored procedures, as demonstrated in Chapter 52, ‘‘Row-Level Security,’’ but views can help enforce row-level security for ad hoc queries. Within Management Studio’s View Designer, the WITH CHECK OPTION can be enforced within the View Properties form. There are actually two properties that must be enabled. The first is (Update Using View Rules), which prohibits Management Studio and MDAC from decoding the view and directly accessing the underlying tables. Only when (Update Using View Rules) is enabled can the second option, WITH CHECK OPTION ,beenabled. Protecting the view Three options protect views from data schema changes and prying eyes. These options are simply added to the CREATE command and applied to the view, in much the same way that the WITH CHECK OPTION is applied. Database code is fragile and tends to break when the underlying data structure changes. Because views are nothing more than stored SQL SELECT queries, changes to the referenced tables may break the view. Creating a view with schema binding locks the underlying tables to the view and prevents changes, as demonstrated in the following code sample: CREATE TABLE dbo.Test ( [Name] NVARCHAR(50) 343 www.getcoolebook.com Nielsen c14.tex V4 - 07/21/2009 12:49pm Page 344 Part II Manipulating Data with Select ); go CREATE VIEW dbo.vTest WITH SCHEMABINDING AS SELECT [Name] FROM dbo.Test; go ALTER TABLE Test ALTER COLUMN [Name] NVARCHAR(100); Result: Msg 5074, Level 16, State 1, Line 1 The object ‘vTest’ is dependent on column ‘Name’. Msg 4922, Level 16, State 9, Line 1 ALTER TABLE ALTER COLUMN Name failed because one or more objects access this column. Some restrictions apply to the creation of schema-bound views. The SELECT statement must include the schema name for any referenced objects, and SELECT all columns (*) is not permitted (but that last requirement shouldn’t bother anyone who follows best practices, says Hugo the Tech Editor). Within Management Studio’s View Designer, the WITH SCHEMA BINDING option can be enabled within the View Properties page. When the schema underlying a view (that is not schema bound) does change, it will likely break the view. If this happens, to repair the view, either recreate it or run the sp_refreshview system stored procedure. Encrypting the view’s select statement The WITH ENCRYPTION option is another security feature. When views or stored procedures are created, the text can be retrieved through the sys.sql_modules and sys.syscomments system views. The code is therefore available for viewing. The view may contain a WHERE condition that should be kept confidential, or there may be some other reason for encrypting the code. The WITH ENCRYPTION option encrypts the code in the system tables, hides them from sys.sql_modules and sys.syscomments, and prevents anyone from viewing the original code. In the following code example, the text of the view is inspected within sys.sql_modules,theviewis encrypted, and sys.sql_modules is again inspected (as expected, the SELECT statement for the view is then no longer readable): SELECT definition FROM sys.sql_modules WHERE object_id = OBJECT_ID(N’dbo.vTest’); 344 www.getcoolebook.com Nielsen c14.tex V4 - 07/21/2009 12:49pm Page 345 Projecting Data Through Views 14 The result is the text of the vText view: definition CREATE VIEW vTest WITH SCHEMABINDING AS SELECT [Name] FROM dbo.Test; The following ALTER command rebuilds the view WITH ENCRYPTION: ALTER VIEW vTest WITH ENCRYPTION AS SELECT [Name] FROM dbo.Test; Be careful with this option. Once the code is encrypted, Management Studio can no longer produce a script to alter the view, and will instead generate this message: /****** Encrypted object is not transferable, and script cannot be generated. ******/ In addition, be aware that the encryption affects replication. An encrypted view will not be published. Application metadata The front-end application or data access layer may request schema information, called meta-data,along with the data when querying SQL Server. Typically, SQL Server returns schema information for the underlying tables, but the WITH VIEW METADATA option tells SQL Server to return schema information about the view, rather than the tables referenced by the view. This prohibits someone from learning about the table’s schema and is useful when the view’s purpose is to hide sensitive columns. Using Synonyms Views are sometimes employed to hide cryptic database schema names. Synonyms are similar to views, but they are more limited. Whereas views can project columns, assign column aliases, and build data using joins and subqueries, synonyms can only assign alternative names to tables, views, and stored procedures. Synonyms are primarily used to simplify complex object names, particularly with lengthy schema names. A synonym can change HumanResources.EmployeeDepartmentHistory into EmpHist.Which would you rather type 100 times? Synonyms are part of the SQL standard and are used frequently by Oracle DBAs. Note that Oracle includes both private and public synonyms. SQL Server synonyms are only public. Even though they 345 www.getcoolebook.com Nielsen c14.tex V4 - 07/21/2009 12:49pm Page 346 Part II Manipulating Data with Select were introduced to SQL Server with version 2005, I’ve seen very little acceptance or use of synonyms in the SQL community. Schemas enhance security and help prevent SQL injection attacks. The hacker needs to guess the schema name as well as the table name. Little Bobby Tables (a standard DBA joke: http://xkcd.com/327/ ) would need to know myschema.students. Giving the table myschema.students an easy to guess synonym would defeat the purpose of using the schema to prevent SQL injection. Synonyms can be managed using Object Explorer, or CREATE and DROP DDL commands. Summary Views are nothing more than stored SQL SELECT queries. There’s no magic in a view. Any valid SQL SELECT statement may be saved as a view, including subqueries, complex joins, and aggregate functions. Views are great for simplifying a complex schema and presenting a more useful picture of the data for power users writing ad hoc queries and reports. Views can simplify complex aggregate queries and hide nasty joins. Any well-planned abstraction layer should include views. My only caution is to not push the view too far. Don’t expect to sort data in a view, and don’t make views the pillar of the front-end appli- cation or website. However, for those who detest views, I suggest that a view is infinitely better than an ad hoc SQL statement that directly hits a table without any abstraction layer. The previous chapters have discussed retrieving data using the powerful SELECT statement. Views store the SELECT statement for ad hoc queries. The next chapter continues the discussion of SELECT, extending its power by adding data modification verbs. 346 www.getcoolebook.com Nielsen c15.tex V4 - 07/21/2009 12:51pm Page 347 Modifying Data IN THIS CHAPTER Inserting data from expressions, other result sets, and stored procedures Updating and deleting data Mastering the new merge command Exposing inserted and de leted tables to the DML T hings change. Life moves on. Because the purpose of a database is to accurately represent reality, the data must change along with reality. For SQL programmers, that means inserting, updating, and deleting rows — using the basic data manipulation language (DML) commands. However, these operations aren’t limited to writing single rows of data. Working with SQL means thinking in terms of data sets. The process of modifying data with SQL draws on the entire range of SQL Server data-retrieval capabilities — the powerful SELECT, joins, full-text searches, subqueries, and views. This chapter is all about modifying data within SQL Server using the INSERT, UPDATE, DELETE,andMERGE SQL commands. Modifying data raises issues that need to be addressed, or at least considered. Inserting surrogate primary keys requires special methods. Table constraints may interfere with the data modification. Referential integrity demands that some DELETE operations cascade to other related tables. This chapter will help you understand these concerns and offer some ways to deal with them. Because these potential obstacles affect INSERT, UPDATE, MERGE, and, to some degree, DELETE, they are addressed in their own sections after the sections devoted to the individual commands. The ACID database properties (atomic, consistent, isolated, and durable) are critical to the modification of data. For many databases, SQL Server’s default transactional control is sufficient. However, misapplied transaction locking and blocking represents one of the top four causes of poor performance. Chapter 66, ‘‘Managing Transactions, Locking, and Blocking,’’ digs into SQL Server’s architecture and explains how data modifications occur within transactions to meet the ACID requirements, and how SQL Server manages data locks. 347 www.getcoolebook.com Nielsen c15.tex V4 - 07/21/2009 12:51pm Page 348 Part II Manipulating Data With Select Best Practice T he SQL INSERT, UPDATE, DELETE,andMERGE commands are really verb extensions of the basic SELECT command. The full potential of the SELECT command lies within each data-modification operation. Even when modifying data, you should think in terms of sets, rather than single rows. Data-modification commands may be submitted to SQL Server from any one of several interfaces. This chapter is concerned more with the strategy and use of the INSERT, UPDATE, DELETE,andMERGE commands than with the interface used to submit a given command to SQL Server. What’s New in Data Modification? T his is an area in which SQL Server 2008 has a few significant new T-SQL features: ■ Row constructors: Insert multiple rows with a single INSERT VALUES statement ■ Merge: Set-based command that can insert, update, or delete for matching or non- matching rows ■ Composable SQL: Builds on SQL Server 2005’s OUTPUT clause and can pass the result of the OUTPUT clause to an outer query. Composable SQL is covered in Chapter 11, ‘‘Including Data with Subqueries and CTEs.’’ SQL Server Management Studio offers two interfaces for submitting SQL commands: Query Designer and Query Editor. If you love a visual UI, then Query Designer may work for a while, but you should migrate to Query Editor to enjoy the richness of T-SQL. I do all my development work exclusively in Query Editor. For more details on using Management Studio’s Query Designer and Query Editor, see Chapter 6, ‘‘Using Management Studio.’’ Inserting Data SQLofferssixformsofINSERT and SELECT/INTO as the primary methods of inserting data (as shown in Table 15-1). The most basic method simply inserts a row of data, while the most complex builds a data set from a complex SELECT statement and creates a table from the result. Each of these INSERT forms is useful for a unique task, often depending on the source of the data being inserted. 348 www.getcoolebook.com Nielsen c15.tex V4 - 07/21/2009 12:51pm Page 349 Modifying Data 15 TABLE 15-1 Insert Forms Insert Form Description INSERT/VALUES Inserts one or more rows of values; commonly used to insert data from a user interface INSERT/SELECT Inserts a result set; commonly used to manipulate sets of data INSERT/EXEC Inserts the results of a stored procedure; used for complex data manipulation INSERT/DEFAULT VALUES Creates a new row with all defaults; used for pre-populating pigeonhole data rows SELECT/INTO Creates a new table from the result set of a SELECT statement MERGE Combines inserting, updating, and deleting data in a single statement SQL Server complements the SQL INSERT commands with other tools to aid in moving large amounts of data or performing complex data conversions. The venerable Bulk Copy Wizard and the Copy Database Wizard are introduced in Chapter 44, ‘‘Transferring Databases.’’ The Copy Database Wizard actually creates a simple Integration Services package. Chapter 37, ‘‘Performing ETL with Integration Services,’’ details Integration Services, a very powerful tool that can move and manipulate large sets of data between/among nearly any data sources. When inserting new data, if the table has surrogate keys, then primary key values must be generated to identify the new rows. While identity columns and GUIDs both make excellent primary keys, each requires special handling during the insertion of rows. This section describes how to create identity-column values and GUIDs. Inserting simple rows of values The simplest and most direct method of inserting data is the INSERT/VALUES method. Until SQL Server 2008, INSERT VALUES was limited to inserting a single row, but SQL Server is now compliant with the ANSI standard and can include row constructors — inserting multiple rows in a single INSERT VALUES statement: INSERT [INTO] schema.table [(columns, )] VALUES (value, ), (value, ), ; Building an INSERT VALUES statement is mostly straightforward, although you do have a few options. The INTO keyword is optional and is commonly ignored. The key to building an INSERT statement is getting the columns listed correctly and ensuring that the data type of the value is valid for the inserted column. 349 www.getcoolebook.com Nielsen c15.tex V4 - 07/21/2009 12:51pm Page 350 Part II Manipulating Data With Select When the values are inserted into a new row, each value corresponds to an insert column. The insert columns may be in any order — the order of the columns within the table is irrelevant — as long as the insert columns and the value columns in the SQL INSERT command are in the same order. As with every chapter that includes code, the file Ch 15 - Modifying Data.sql on www.SQLServerBible.com contains all the sample code for this chapter. Additional examples of data-modification statements may be found in any of the sample database ‘‘populate’’ scripts, or in the stored procedures of the OBXKites sample database. The following INSERT commands reference the columns in varying order, inserting one row and then multiple rows: USE CHA2 INSERT INTO dbo.Guide (FirstName, LastName) VALUES (’Tammie’, ‘Commer’); INSERT INTO dbo.Guide (LastName, FirstName, Qualifications) VALUES (’Smith’, ‘Dan’, ‘Diver, Whitewater Rafting’), (’Jeff’, ‘Davis’, ‘Marine Biologist, Diver’); The following SELECT command verifies the insert: SELECT GuideID, LastName, FirstName, Qualifications FROM dbo.Guide; Result (your result may differ depending on the data loaded into the database): GuideID LastName FirstName Qualifications 1 Smith Dan Diver, Whitewater Rafting 2 Davis Jeff Marine Biologist, Diver 3 Commer Tammie NULL Not every column in the table has to be listed, but if a column appears, then a value has to be avail- able for the INSERT command. The first INSERT statement in the previous sample code omitted the Qualifications column. The INSERT operation worked nonetheless and inserted a NULL into the omitted column. If the Qualifications column had a default constraint, then the default value would have been inserted instead of the NULL. When a column has both no default and a NOT NULL constraint, and no value is provided in the INSERT statement, the INSERT operation will fail. (For more information about inserting defaults and nulls, see the section ‘‘Potential Data-Modification Obstacles’’ later in this chapter.) It’s possible to explicitly force the INSERT of a default without knowing the default value. If the key- word DEFAULT is provided in the value-column list, then SQL Server will store the default value for the column. This is a good practice because it documents the intention of the code, rather than leaving the code blank and assuming the default. The insert-column list is required when using row constructors to insert multiple rows. 350 www.getcoolebook.com Nielsen c15.tex V4 - 07/21/2009 12:51pm Page 351 Modifying Data 15 Explicitly listing the columns is a good idea. It prevents an error if the table schema changes, and it helps document the insert. However, the insert-column list is optional. In this case, the values are inserted into the table according to the order of the columns in the table (ignoring an identity column). It’s critical that every table column receive valid data from the value list. Omitting a column in the value list causes the INSERT operation to fail. You learned earlier that when the columns are explicitly listed within the INSERT/VALUES command, an identity column can’t receive a value. Similarly, the identity column is also ignored in the value list when the columns are assumed. The rest of the values are in the same order as the columns of the Guide table, as follows: INSERT Guide VALUES (‘Jones’, ‘Lauren’, ‘First Aid, Rescue/Extraction’,‘19590625’,‘200104415’); To view the inserted data, the following SELECT command pulls data from the Guide table: SELECT GuideID, LastName, FirstName, Qualifications FROM dbo.Guide; Result: GuideID LastName FirstName Qualifications 1 Smith Dan Diver, Whitewater Rafting 2 Davis Jeff Marine Biologist, Diver 3 Commer Tammie NULL 4 Jones Lauren First Aid, Rescue/Extraction So far in the sample code, values have been hard-coded string literals. Alternately, the value could be returned from an expression. This is useful when a data type requires conversion, or when data need to be altered, calculated, or concatenated: INSERT dbo.Guide (FirstName, LastName, Qualifications) VALUES (‘Greg’, ‘Wilson’, ‘Rock Climbing’ + ‘, ’ + ‘First Aid’); The next SELECT statement verifies Greg’s insert: SELECT GuideID, LastName, FirstName, Qualifications FROM dbo.Guide; Result: GuideID LastName FirstName Qualifications 1 Smith Dan Diver, Whitewater Rafting 2 Davis Jeff Marine Biologist, Diver 3 Commer Tammie NULL 4 Jones Lauren First Aid, Rescue/Extraction 351 www.getcoolebook.com . meta-data,along with the data when querying SQL Server. Typically, SQL Server returns schema information for the underlying tables, but the WITH VIEW METADATA option tells SQL Server to return schema information about. interface used to submit a given command to SQL Server. What’s New in Data Modification? T his is an area in which SQL Server 2008 has a few significant new T -SQL features: ■ Row constructors: Insert. synonyms. SQL Server synonyms are only public. Even though they 345 www.getcoolebook.com Nielsen c14.tex V4 - 07/21/2009 12:49pm Page 346 Part II Manipulating Data with Select were introduced to SQL Server