Hướng dẫn học Microsoft SQL Server 2008 part 27 pps

Data Types, Expressions, and Scalar Functions 9■ SERVERPROPERTY: Several useful pieces of information about the server may be deter-mined from this function, including the following: ■ C

Kennedy 3

The advantage of theDIFFERENCE()function is that it broadens the search beyond the first letters

The problem with the function is that it wants to calculate the Soundex value for both parameters,

which prevents it from taking advantage of pre-stored Soundex values

Data-Type Conversion Functions

Converting data from one data type to another data type is often handled automatically by SQL Server

Many of those conversions are implicit, or automatic

Conversions that are explicit require aCAST()orCONVERT()function:

■ CAST(Input as data type): The ANSI standard SQL means of converting from one data type to another Even when the conversion can be performed implicitly by SQL Server, using theCAST()function forces the desired data type

CAST()is actually programmed slightly differently than a standard function Rather than separate the two parameters with a comma (as most functions do), the data passed to the

CAST()function is followed by theaskeyword and the requested output data type:

SELECT CAST(’Away’ AS NVARCHAR(5)) AS ‘Tom Hanks’

Result:

TOM HANKS -AWAY

■ Another example:

SELECT CAST(123 AS NVARCHAR(15)) AS Int2String

Result:

INT2STRING -123

■ CONVERT(datatype,expression,style): Returns a value converted to a different data type with optional formatting The first parameter of this non-ANSI SQL function is the desired data type to be applied to the expression:

CONVERT (data type, expression[, style])

Data Types, Expressions, and Scalar Functions 9

Thestyleparameter usually refers to the optional date styles listed in Table 9-3 The style

is applied to the output during conversion from datetime to a character-based data type, or to

the input during conversion from text to datetime Generally, the one- or two-digit style

pro-vides a two-digit year, and its three-digit counterpart propro-vides a four-digit year For example,

style 1 provides 01/01/03, whereas style 101 provides 01/01/2003 The styles marked with an

asterisk (*) in Table 9-3 are the exceptions to this rule

SQL Server also provides numeric formatting styles, but numeric formatting is typically the

task of the user interface, not the database

TABLE 9-3

Convert Function Date Styles

9 or 109∗ Default+milliseconds mon dd yyyy hh:mi:ss:mmmAM (or PM)

13 or 113∗ Europe default+milliseconds dd mon yyyy hh:mm:ss:mmm (24h)

21 or 121∗ ODBC canonical+ milliseconds yyyy-mm-dd hh:mi:ss.mmm (24h)

∗Both styles return dates with centuries.

Best Practice

In a clean client/server design, the server provides the data in an internal format and the client application

formats the data as required by the user Unformatted data is more independent than formatted data and

can be used by more applications

The following code demonstrates theCONVERT()function:

SELECT CURRENT_TIMESTAMP AS RawDate, CONVERT (NVARCHAR(25), CURRENT_TIMESTAMP, 100) AS Date100, CONVERT (NVARCHAR(25), CURRENT_TIMESTAMP, 1) AS Date1;

Result:

- -

An additional data-type conversion function provides a fast way to move data between text and numeric:

■ STR(number,length,decimal): Returns a string from a number:

SELECT STR(123,6,2) AS [Str];

Result:

Str -123.00

Server Environment Information

System functions return information about the current environment This section covers the more

com-monly used system functions:

■ DB_NAME(): Returns the name of the current database, as shown in the following example:

SELECT CURRENT_TIMESTAMP AS [Date], DB_NAME() AS [Database];

Result:

-

Data Types, Expressions, and Scalar Functions 9

■ SERVERPROPERTY(): Several useful pieces of information about the server may be

deter-mined from this function, including the following:

■ Collation: The collation type

■ Edition: Enterprise, Developer, Standard, and so on

■ EngineEdition: 2= Standard, 3 = Enterprise, 4 = Express

■ InstanceName: Null if the default instance

■ ProductVersion: The version number of SQL Server

■ ProductLevel: ‘‘RTM’’ for the initial release-to-manufacturing version, ‘‘SPn’’ for service

packs (n is the service pack number), ‘‘CTP’’ for Community Technology Preview versions

■ ServerName: The full server and instance name

For example, the following code returns SQL Server engine edition and version information for

my current instance of SQL Server:

SELECT

SERVERPROPERTY (’ServerName’) AS ServerName,

SERVERPROPERTY (’Edition’) AS Edition,

SERVERPROPERTY (’ProductVersion’) AS ‘ProductVersion’,

SERVERPROPERTY (’ProductLevel’) AS ProductLevel;

Result:

- - -

Summary

The previous chapter introduced the basicSELECTstatement and query flow This chapter expanded

the concept with expressions and calculations that can be inserted in several places within the query,

significantly improving its flexibility In subsequent chapters, you will see how expressions can receive

data from subqueries and user-defined functions, further increasing the power of the query

The next chapter continues the progression of adding capability to the query by joining data from

multiple data sources

Merging Data with Joins

and Unions

IN THIS CHAPTER

Applying relational algebra Building scalable code with set-based queries

Using inner, outer, complex,

and  (theta) joins

Merging data vertically with unions

The introduction to this book stated that my purpose was to share the fun

of developing with SQL Server This chapter is it Making data twist and

shout, pulling an answer out of data with a creative query, replacing a

few hundred lines of languishing row-by-row iterative code with a single blazingly

fast, set-based SQL query — it’s all pure fun and covered here

Relational databases, by their very nature, segment data into several narrow,

but long, tables Seldom does looking at a single table provide meaningful

data Therefore, merging data from multiple tables is an important task for SQL

developers The theory behind merging data sets is relational algebra, as defined

by E F Codd in 1970

Relational algebra consists of eight relational operators:

■ Restrict: Returns the rows that meet a certain criterion

■ Project: Returns selected columns, or calculated data, from a data set

■ Product: Relational multiplication that returns all possible combinations

of data between two data sets

■ Union: Relational addition and subtraction that merges two tables

vertically by stacking one table above another table and lining up the

columns

■ Intersection: Returns the rows common to two data sets

■ Difference: Returns the rows unique to one data set

■ Join: Returns the horizontal merger of two tables, matching up rows

based on common data

■ Divide: The inverse of relational multiplication, returns rows in one

data set that match every row in a corresponding data set

In addition, as a method of accomplishing relational algebra, SQL has implemented the following:

■ Subqueries: Similar to a join, but more flexible; the results of the subquery are used in place

of an expression, list, or data set within an outer query

In the formal language of relational algebra:

■ A table, or data set, is a relation or entity.

■ A row is a tuple.

■ A column is an attribute.

However, I use the common terms of table, row, and column throughout this chapter

Relational theory is now thirty-something and has become better defined over the years as database

ven-dors compete with extensions, and database theorists further define the problem of representing reality

within a data structure However, E F Codd’s original work is still the foundation of relational database

design and implementation

To give credit where credit is due, this entire chapter is based on the work of E F Codd and C J Date You can find a complete list of recommended resources in the Resources page on www.SQLServerBible.com

Keep in mind that joins work with more than just tables As listed in Chapter 8, ‘‘Introducing Basic

Query Flow,’’ data sources include local SQL Server tables, subqueries/CTEs, views, table-valued

user-defined functions, distributed data sources (other database tables), full-text search results, and

XQueries

The reason for writing set-based queries is more than just writing elegant code Set-based queries scale

extremely well My last consulting contract was developing an OLTP system with a few complexities

that required 35,000 transactions per second The system was able to work at that tps rate because the

database design enabled set-based queries within stored procedures So, while this chapter may seem

like it just focuses on writing queries, it’s really setting you up to write better stored procedures

Using Joins

In relational algebra, a join is the multiplication of two data sets followed by a restriction of the result

so that only the intersection of the two data sets is returned The whole purpose of the join is to

hori-zontally merge two data sets and produce a new result set from the combination by matching rows in

one data source to rows in the other data source, as illustrated in Figure 10-1 This section explains the

various types of joins and how to use them to select data

By merging the data using the join, the rest of the SQLSELECTstatement, including the column

expressions, aggregate groupings, andWHEREclause conditions, can access any of the columns or rows

from the joined tables These capabilities are the core and power of SQL

Merging Data with Joins and Unions 10

FIGURE 10-1

A join merges rows from one data set with rows from another data set, creating a new set of rows that

includes columns from both In this diagram, the code, 101, is common to Smith and order number

1, and is used to merge the two original rows into a single result row

Name

Smith

Code

101

Name Smith

Code 101

Code 101

Order 1

Order 1

What’s New with Joins and Unions?

Joins and unions are at the heart of SQL, so change here occurs slowly The only item to watch for with

joins and unions is the ANSI 89 style outer joins

If you’re upgrading from SQL Server 2000 directly to SQL Server 2008, you should be warned that ANSI 89

style outer joins (*=, =*) were removed from SQL Server with version 2005 ANSI 89 style inner joins may

be a legitimate syntax, but I still don’t recommend using them

I apologize if this sounds too much like your teenager’s math homework, but joins are based on the idea

of intersecting data sets As Figure 10-2 illustrates, a relational join deals with two sets of data that have

common values, and it’s these common values that define how the tables intersect

FIGURE 10-2

Relational joins are based on the overlap, or common intersection, of two data sets

Data Set A Data Set B

Common Intersection

These set diagrams are a type of Venn diagram For more information about Venn set diagrams, visit www.combinatorics.org/Surveys/ds5/VennEJC.html or Wikipedia.

The intersection simply represents the fact that some common column can connect a row from the first

data set to data in the second data set The common values are typically a primary key and a foreign

key, such as these examples from theOBXKitessample database:

■ ContactIDbetween theContactand[Order]tables

■ OrderIDbetween the[Order]andOrderDetailtables

■ ProductIDbetween theProductandOrderDetailtables SQL includes many types of joins that determine how the rows are selected from the different sides of

the intersection Table 10-1 lists the join types (each is explained in more detail later in this section)

TABLE 10-1

Join Types

Join Type Query Designer Symbol Definition

Left outer

join

Includes all rows from the left table regardless of whether a match exists, and matching rows from the right table

Right outer

join

Includes all the rows from the right table regardless of whether a match exists, and matching rows from the left table

Full outer

join

Includes all the rows from both tables regardless of whether a match exists

(theta)

join

Matches rows using a non-equal condition — the symbol

shows the actual theta condition (<,>,<=,>=,<>)

Cross join No join connection Produces a Cartesian product — a match between each row

in data source one with each row from data source two without any conditions or restrictions

Inner Joins

The inner join is by far the most common join In fact, it’s also referred to as a common join, and was

originally called a natural join by E F Codd The inner join returns only those rows that represent a

match between the two data sets An inner join is well named because it extracts only data from the

inner portion of the intersection of the two overlapping data sets, as illustrated in Figure 10-3

Merging Data with Joins and Unions 10

FIGURE 10-3

The inner join includes only those rows from each side of the join that are contained within the

intersection of the two data sources

Inner Join

Data Set A Data Set B

Common Intersection

Building inner joins with the Query Designer

Inner joins are easily constructed within Management Studio using the Query Designer UI, as shown in

Figure 10-4 Once both tables have been placed in the Diagram pane either using the Add Table

func-tion or by dragging the tables from the table list, the join automatically creates the required common

joins based on common fields

Any unwanted joins can be removed by selecting the join and pressing Delete To create a new join

between two tables, drag the join column from the first table to the second table The type of join can

be changed by right-clicking on the join type symbol

The Query Designer uses a different symbol for each type of join The symbol for an inner join, the join

diamond, is an accurate illustration of that type of join.

Creating inner joins within SQL code

Using T- SQL code, joins are specified within theFROMportion of theSELECTstatement The keyword

JOINidentifies the second table, and theONclause defines the common ground between the two tables

The default type of join is an inner join, so the keywordINNERis optional For clarity, however, I

rec-ommend always including it:

SELECT *

FROM Table1

[INNER] JOIN Table2

ON Table1.column = Table2.column;

ON the WEBSITE The sample databases and code from this chapter may be downloaded from www.SQLServerBible.com.