Tải bản đầy đủ (.pdf) (60 trang)

Chuẩn bị cho kỳ thi 733 về Phát triển ứng dụng DB2 9, Phần 8: Lập trình nâng cao pot

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (5.17 MB, 60 trang )

Chuẩn bị cho kỳ thi 733 về Phát triển ứng dụng DB2 9, Phần 8: Lập trình
nâng cao
Các kiểu dữ liệu do người dùng định nghĩa, xem xét sự tương tranh và nhiều hơn
nữa
Ted J. Wasserman, Tư vấn CSDL, IBM
Tóm tắt: Hướng dẫn này nghiên cứu các kỹ năng lập trình nâng cao cần thiết để
viết các ứng dụng có tương tác với DB2® 9. Các chủ đề bao gồm các kiểu dữ liệu
do người dùng xác định (UDTs), tạo kiểu dữ liệu, các dấu tham số, SQL phức hợp,
các bộ bẫy sự kiện, các phần phân tán của công việc, cơ sở dữ liệu có liên kết và
khía cạnh tương tranh. Đây là bài thứ tám trong loạt bài gồm chín bài hướng dẫn
mà bạn có thể sử dụng để giúp chuẩn bị cho kỳ thi lấy chứng chỉ phát triển ứng
dụng DB2 9 (kỳ thi 733).
Trước khi bạn bắt đầu
Hướng dẫn này gồm những gì?
Hướng dẫn này dẫn bạn đi qua một số các kỹ năng lập trình nâng cao cần thiết để
viết các ứng dụng có tương tác với DB2 9. Trong hướng dẫn này, bạn sẽ học cách
làm thế nào để :
 Sử dụng các kiểu dữ liệu do người dùng định nghĩa (UDT) và thực hiện tạo
khuôn mẫu kiểu dữ liệu.
 Sử dụng các dấu tham số.
 Sử dụng SQL ghép.
 Tạo các bộ khởi động.
 Hiểu được khái niệm về các đơn vị công việc được phân phối và các môi
trường cơ sở dữ liệu được liên kết.
 Hiểu cách DB2 xử lý tương tranh.
Đây là bài thứ tám trong loạt bài gồm chín hướng dẫn mà bạn có thể sử dụng để
trợ giúp chuẩn bị cho kỳ thi cấp chứng chỉ phát triển ứng dụng DB2 9 (kỳ thi 733).
Các tài liệu trong hướng dẫn này chủ yếu bao gồm các mục tiêu trong phần 8 của
kỳ thi, mang tên "Lập trình nâng cao". Ngay sau đây, bạn sẽ có thể xem các mục
tiêu này tại
Bạn không cần một bản sao của DB2 để hoàn thành hướng dẫn này. Tuy nhiên,


bạn có thể tải về một bản DB2 Express C miễn phí từ trang Web DB2 Express-C
để thực hành các kỹ năng của bạn.
Xin lưu ý rằng một số tài liệu được thảo luận trong hướng dẫn này chỉ áp dụng với
DB2 cho Linux™, UNIX® và Windows® và không cho DB2 trên nền tảng khác,
chẳng hạn như Hệ thống z hoặc Hệ thống i.


Ai nên dùng hướng dẫn này?
Hướng dẫn này được thiết kế cho bất kỳ ai quan tâm đến việc học tập về các khái
niệm lập trình DB2 nâng cao và chuẩn bị cho kỳ thi lấy chứng chỉ phát triển ứng
dụng DB2 9 (kỳ thi 733).
Trước khi tham dự kỳ thi cấp chứng chỉ Phát triển ứng dụng DB2 9, bạn đã phải
vượt qua được kỳ thi về các khái niệm cơ bản của Họ DB2 9 (kỳ thi 730). Bạn có
thể sử dụng "Loạt bài hướng dẫn các khái niệm cơ bản của DB2" (xem Tài
nguyên) để chuẩn bị cho kỳ thi đó.
Để hướng dẫn này có ích, bạn nên có kiến thức chắc chắn về cách một cơ sở dữ
liệu quan hệ làm việc như thế nào, cũng như các kiến thức cơ bản về:
 Các câu lệnh SQL.
 Các đối tượng cơ sở dữ liệu.
 Phát triển ứng dụng.


Xem xét lại thuật ngữ
Trước khi bắt đầu hướng dẫn này, bạn nên hiểu rõ khái niệm về một kế hoạch truy
cập SQL. Nói ngắn gọn, một kế hoạch truy cập là tập hợp các bước mà DB2 sử
dụng để thực hiện một câu lệnh SQL và truy cập dữ liệu. Nó bao gồm các chỉ mục
được sử dụng, các thời điểm trong đó các trường được lấy ra từ các bảng cơ sở dữ
liệu và thứ tự các bước có thực hiện truy vấn. Kế hoạch truy cập được một máy cơ
sở dữ liệu tạo ra dựa trên câu lệnh SQL được đệ trình. Lý tưởng là cơ sở dữ liệu
lựa chọn kế hoạch truy cập "tối ưu" nhất đó là, kế hoạch sẽ trả về dữ liệu một

cách hiệu quả và nhanh chóng nhất.


Các lưu ý và các thương hiệu
Bản quyền, IBM Corporation 2007. Giữ bản quyền.
IIBM, DB2, WebSphere Federation Server, WebSphere và WebSphere MQ là các
thương hiệu hoặc các thương hiệu được đăng ký của IBM Corporation ở Mỹ, các
nước khác, hoặc cả hai.
Công ty, sản phẩm và các tên dịch vụ khác có thể là các thương hiệu hoặc nhãn
hiệu dịch vụ của người khác.


Các kiểu dữ liệu do người dùng định nghĩa và tạo khuôn mẫu kiểu dữ liệu
Các kiểu dữ liệu do người dùng định nghĩa là gì?
Các kiểu dữ liệu do người dùng định nghĩa hoặc các kiểu thường được gọi là các
UDT, là các kiểu dữ liệu mà bạn có thể tạo ra dựa trên các kiểu dữ liệu DB2, như
là các kiểu dữ liệu INTEGER (số nguyên) hay CHAR. Các UDT thậm chí có thể
dựa vào các UDT khác.
Các UDT được sử dụng để thiết lập ngữ cảnh của một biến. Chúng cho phép bạn
theo dõi một đối tượng đang được sử dụng trong ứng dụng của bạn như thế nào.
Bạn cũng có thể xác định các mối quan hệ giữa các kiểu dữ liệu khác nhau và các
UDT.
Xem xét một ví dụ đơn giản. Giả sử bạn có một ứng dụng, nó xác định các lộ trình
tốt nhất giữa các cửa hàng ở Mỹ và Canada. Để làm điều này, bạn phải làm việc
với các khoảng cách bằng cả hai hệ thống đo lường theo mét và theo hệ thống đo
lường Anh. Bạn không thể biết được dữ liệu trong một bảng được lưu giữ theo km
hoặc theo dặm (miles). Bạn có thể sử dụng một UDT để tạo ra một kiểu KM và
một UDT khác là kiểu MILES. Bằng cách sử dụng cụ thể các kiểu này, kiểu hệ
thống đo lường nào đang được lưu trữ trong bảng của bạn sẽ rõ ràng hơn. Bạn
cũng có thể viết một hàm để tự động thêm các kiểu KM và MILES với nhau theo

đúng cách.

Hình 1. Các UDT: KM so với MILES



Tạo một UDT
Bạn có thể tạo một UDT khi sử dụng câu lệnh CREATE DISTINCT TYPE. Sơ đồ
cú pháp của câu này là như sau:
-CREATE DISTINCT TYPE distinct-type-name AS >
| source-data-type | WITH COMPARISONS |

Kiểu dữ liệu nguồn có thể là bất kỳ kiểu dữ liệu chuẩn nào được DB2 sử dụng, trừ
XML.
Dưới đây là một vài ví dụ:
CREATE DISTINCT TYPE km AS INTEGER WITH COMPARISONS
CREATE DISTINCT TYPE miles AS INTEGER WITH COMPARISONS

Khi UDT được tạo thành công, DB2 tự động tạo ra các toán tử so sánh chuẩn (=,
<>, <, <=, > và >=) mà bạn có thể sử dụng.
Cấp phép
Các quyền do cấp phép ID tạo nên UDT cần có ít nhất các thứ sau:
 Quyền SYSADM hay DBADM.
 Quyền IMPLICIT_SCHEMA trên cơ sở dữ liệu (nếu tên lược đồ của kiểu
khác biệt không dựa vào một lược đồ hiện có).
 Đặc quyền CREATEIN trên lược đồ (nếu tên lược đồ của kiểu khác biệt
dựa vào một lược đồ hiện có).


Sử dụng một UDT

Các nhà phát triển mới với DB2 đôi khi gặp phải các lỗi khi lần đầu tiên họ bắt
đầu làm việc với các UDT, bởi vì các UDT tương tác khác nhau với các kiểu dữ
liệu chính quy và các kiểu khác. Bình thường, DB2 tự động tạo khuôn mẫu một
kiểu dữ liệu cho bạn để cho phép bạn thực hiện các phép tính số học hoặc so sánh.
Tuy nhiên, với các UDT, điều này không phải luôn luôn xảy ra.
Tạo khuôn mẫu kiểu mạnh
DB2 không tự động dịch (hoặc tạo khuôn mẫu) các kiểu dữ liệu từ một kiểu này
sang một kiểu khác. Một số kiểu dữ liệu sẽ được tự động tạo khuôn mẫu nếu
chúng là một phần của cùng nhóm kiểu dữ liệu, như được chỉ ra trong Hình 2. Nếu
chúng không phải là một phần của cùng một nhóm, một lỗi xuất hiện.

Hình 2. Các nhóm kiểu dữ liệu DB2

Ví dụ, đoạn mã sau đây có lỗi trong DB2:
empno = CHAR(6) {but the data is always numeric}
SQL String: SELECT (empno + 1) AS new_emp_no FROM employee

Câu lệnh này sai vì bạn không thể thêm số nguyên "1" vào dữ liệu ký tự, thậm chí
nếu dữ liệu đó biểu diễn chuỗi của một số.


Tạo khuôn mẫu
Để so sánh hoặc thực hiện các phép toán số học bằng cách sử dụng các UDT hoặc
các kiểu dữ liệu khác nhau, bạn có thể tạo khuôn mẫu một trong số chúng theo
cùng một kiểu dữ liệu khi sử dụng đặc tả CAST. Cú pháp của đặc tả này được hiển
thị dưới đây:
CAST ( objectName AS target-data-type ) |

Dưới đây là một ví dụ:
CAST (empno AS INTEGER)


Hãy xem xét một số ví dụ khác. Đầu tiên, tạo một cặp các kiểu riêng biệt và một
bảng sử dụng chúng:
CREATE DISTINCT TYPE km AS INTEGER WITH COMPARISONS;
CREATE DISTINCT TYPE miles AS INTEGER WITH COMPARISONS;

CREATE TABLE cityInfo (
cityName CHAR(20),
width_k KM NOT NULL,
width_m MILES NOT NULL
);


Câu lệnh SQL dưới đây thực hiện thành công vì các kiểu dữ liệu đang được so
sánh trong mệnh đề WHERE được biến đổi (ép kiểu) phù hợp với cùng kiểu dữ
liệu. Câu lệnh SQL biến đổi các số nguyên "10" thành một kiểu KM cho phép so
sánh này.
SELECT cityName
FROM cityInfo
WHERE width_k > km(10)

Bây giờ hãy thay đổi câu lệnh ở trên để mô phỏng một lỗi phổ biến. Câu lệnh dưới
đây không làm việc vì DB2 không biết cách so sánh các kiểu dữ liệu MILES và
KM như thế nào:
SELECT cityName
FROM cityInfo
WHERE width_k > width_m

Tuy nhiên, câu lệnh sau thực hiện thành công vì các kiểu dữ liệu có cả hai tạo
khuôn mẫu theo kiểu số nguyên INTEGER.

SELECT cityName
FROM cityInfo
WHERE CAST(width_k AS INTEGER) > CAST(width_m AS INTEGER)

Các dấu tham số
Các dấu tham số là gì?
Các dấu tham số là các ký hiệu số hạng cho các biến trong câu lệnh SQL. Một ký
tự dấu hỏi (?) biểu diễn chúng. Việc sử dụng dấu tham số làm giảm số lượng các
câu lệnh SQL cần được biên dịch và tối ưu hóa. Bạn có thể tự hỏi tại sao bạn sẽ sử
dụng dấu tham số trong ứng dụng của bạn nếu bạn đang sử dụng SQL động và mỗi
lần phải xây dựng chuỗi câu lệnh. Bạn sẽ tìm hiểu câu trả lời ngắn gọn cho câu hỏi
này.
Điều quan trọng là hãy nhớ rằng một dấu tham số thay thế một giá trị bằng chữ,
như câu lệnh SQL sau đây minh hoạ:
SELECT firstname, lastname
FROM employee
WHERE empno = ?

SELECT firstname, lastname
FROM employee
WHERE hiredate > ?
AND mgrno = ?

Chúng ta hãy xem xét ba ví dụ cho thấy các lỗi phổ biến của nhà phát triển khi sử
dụng các dấu tham số. Đây là ví dụ đầu tiên:
SELECT ?, lastname
FROM employee
WHERE empno = ?

Câu lệnh SQL ở trên sử dụng một dấu tham số ở vị trí của một tên cột trong danh

sách SELECT. DB2 cần biết các cột mà các dữ liệu đang được tìm để tối ưu hóa
một truy vấn. Các cột được sử dụng có ảnh hưởng lớn đến cách DB2 lấy dữ liệu.
Ví dụ, chúng có thể xác định lựa chọn giữa chỉ mục hoặc quét bảng.
Hãy xem một ví dụ khác về mã không đúng:
SELECT firstname, lastname
FROM ?
WHERE empno = ?

Trong ví dụ này, một tham số được sử dụng trong mệnh đề FROM thay vì một tên
bảng. DB2 không có khả năng xác định cái bảng trích dữ liệu, do đó không có
cách nào để câu lệnh SQL này có thể được dịch.
Và bây giờ, một ví dụ cuối cùng:
SELECT firstname, lastname
FROM employee
WHERE ? = 14
AND ? = ?

Ví dụ này sử dụng các dấu tham số trong mệnh đề WHERE. Đầu tiên nó sử dụng
một dấu tham số để biểu diễn trường mà giá trị 14 sẽ được kiểm tra. Nó cũng sử
dụng hai dấu tham số để xác định cột và trường giá trị trong vị từ thứ hai. Trong
trường hợp này, DB2 không có khả năng xác định đâu là vị từ và đâu là giá trị, do
đó, nó không thể dịch câu lệnh.


Những ưu điểm của việc sử dụng dấu tham số
Các dấu tham số đưa ra một số lợi thế. Ưu điểm chính là giảm thời gian dịch, đầu
tiên DB2 chuẩn bị một câu lệnh SQL trước khi nó có thể được thực hiện. Trong
giai đoạn chuẩn bị, kế hoạch truy cập được tạo để xác định cách tìm dữ liệu. Khi
câu SQL được dịch, DB2 kiểm tra một phần của bộ nhớ cơ sở dữ liệu được gọi là
"bộ nhớ nhanh gói", nó chứa các câu lệnh SQL được thực hiện gần nhất và các kế

hoạch truy cập có liên quan của chúng. Nếu một câu lệnh trong bộ nhớ nhanh
khớp với câu lệnh được đệ trình để thực hiện, DB2 có thể tái sử dụng nó và không
phải biên dịch nó một lần nữa.
Đối với câu lệnh trong bộ nhớ nhanh gói được tái sử dụng, câu lệnh được đệ trình
phải khớp với câu lệnh trong bộ nhớ nhanh một cách chính xác. Hãy xem xét một
số ví dụ minh họa việc khớp ra sao. Giả sử rằng câu lệnh sau là bản gốc trong bộ
nhớ nhanh gói:
SELECT deptName, location
FROM department
WHERE mgrno = '000056'

Đây sẽ là một câu lệnh ăn khớp:
SELECT deptName, location
FROM department
WHERE mgrno = '000056'

Tuy nhiên, không câu lệnh nào trong các câu lệnh sau sẽ được coi là các câu lệnh
ăn khớp:
SELECT deptName, location
FROM department
WHERE mgrno = '000055'

SELECT deptName, location
FROM department
WHERE mgrno = ?

SELECT deptName, location
FROM department
WHERE mgrno = :varMgrno


Câu lệnh không khớp đầu tiên không thực hiện thành công vì '000055' không
giống '000056'. DB2 sử dụng sự khớp văn bản trực tiếp để xem xét các câu lệnh có
giống nhau không. Câu lệnh không khớp thứ hai không thực hiện thành công vì
dấu tham số không khớp với '000055'. Ví dụ thứ ba không thực hiện thành công
cũng cùng lý do đó.
Tuy nhiên, nếu một dấu tham số đã được sử dụng trong câu lệnh ban đầu, bất kỳ
sự đệ trình của cùng câu lệnh khi sử dụng một dấu tham số sẽ ăn khớp. Câu lệnh
SQL khi sử dụng dấu tham số sau đó có thể được thực hiện bằng cách sử dụng bất
kỳ giá trị được cung cấp trong thời gian chạy, ví dụ như '000055', '005600',
'000123' v.v.
Dưới đây là một ví dụ minh họa khái niệm này ở mức độ sâu hơn. Hãy tưởng
tượng rằng phần sau đây là câu lệnh ban đầu trong bộ nhớ nhanh gói:
SELECT deptName, location
FROM department
WHERE mgrno = ?

Câu lệnh sau đây sẽ ăn khớp với nó:
SELECT deptName, location
FROM department
WHERE mgrno = ?

Câu lệnh sau đây không ăn khớp với nó:
SELECT deptName, location
FROM department
WHERE mgrno = 55

Lợi thế của việc không phải biên dịch một câu lệnh trở nên rõ ràng hơn khi bạn
xem xét đến thời gian biên dịch một câu lệnh. Hãy tưởng tượng một truy vấn có
một thời gian biên dịch là 0,001 giây và thời gian thực hiện là 0,001 giây. Phải mất
bao lâu để thực hiện truy vấn đó 10.000 lần? Đây là một công thức đơn giản để

xác định tổng thời gian:
Total statement time = statement compilation time + statement execution time

Khi sử dụng dấu tham số, kết quả sẽ là:
0.001 + (10000 * 0.001) = 10.001 seconds

Nói cách khác, bạn phải chịu một chi phí một lần để biên dịch câu lệnh, sau đó
phải chịu chi phí thực hiện câu lệnh 10.000 lần. Nếu bạn không sử dụng các dấu
tham số và câu lệnh đều đã yêu cầu biên dịch mỗi lần vì không thể tìm thấy trong
bộ nhớ nhanh gói một sự ăn khớp này, kết quả sẽ là:
(10000 * 0.001) + (10000 * 0.001) = 20 seconds

Trong trường hợp này, bạn phải chịu chi phí biên dịch và chi phí thực hiện mỗi
lần. Như ví dụ đơn giản này minh hoạ, việc sử dụng một dấu tham số cắt đi một
nửa tổng thời gian thực hiện câu lệnh!
Mỗi ngôn ngữ lập trình có cách riêng để cung cấp giá trị thực cho các tham số
trong thời gian chạy. Liệt kê 1 cho thấy một ví dụ về một thủ tục SQL viết sẵn có
sử dụng dấu tham số trong một câu lệnh đã chuẩn bị, sau đó cung cấp các giá trị
cho các dấu tham số trước khi thực hiện câu lệnh.

Liệt kê 1. Sử dụng các dấu tham số bên trong một thủ tục viết sẵn

CREATE PROCEDURE SIMPLE
_UPDT_PROC (IN p_emp_id SMALLINT,
IN p_new_salary DECIMAL)
LANGUAGE SQL
BEGIN

DECLARE v_sqltext VARCHAR(1000);


SET v_sqltext = 'UPDATE STAFF SET salary=? WHERE id=?';

PREPARE v_stmt1 FROM v_sqltext;
EXECUTE v_stmt1 USING p_new_salary, p_emp_id;

END

Trong thủ tục này, một câu lệnh UPDATE chứa hai dấu tham số được chuẩn bị
đầu tiên, sau đó được thực hiện. Do câu lệnh được chuẩn bị với các dấu tham số,
việc gọi thủ tục tiếp theo không đòi hỏi dịch lại câu lệnh, bởi vì sẽ có thể tìm thấy
trong bộ nhớ nhanh gói câu lệnh đó. Các giá trị của tham số thực được cung cấp
cho các tham số như một phần của câu lệnh EXECUTE với mệnh đề USING.


Những bất lợi của việc sử dụng dấu tham số
Việc sử dụng dấu tham số cũng có thể có mặt trái. Những bất lợi chính là thiếu
thông tin về các giá trị tham số. Khi bạn sử dụng một dấu tham số, DB2 không
biết giá trị của tham số này là gì khi nó biên dịch câu lệnh. Trong thời gian thực
hiện, nó thay thế giá trị do người sử dụng tạo ra cho dấu tham số. Điều này có thể
gây ra các vấn đề nếu giá trị của biến có tác động lớn đến kế hoạch truy cập SQL
được chọn.
Ví dụ, hãy xem xét một bảng có tên là "BIGTABLE" chứa thông tin về đồ chơi.
Giả sử có 50.000 đồ chơi màu đỏ, 5 đồ chơi màu nâu, 800.000 đồ chơi màu hồng
và 75.000 đồ chơi màu xanh lá cây. Ứng dụng này truy vấn cơ sở dữ liệu để tìm
hiểu có bao nhiêu đồ chơi đang được bán ra. Dưới đây là định nghĩa bảng:
CREATE TABLE toyLists (
id INTEGER NOT NULL,
color CHAR(10),
type CHAR(10),
price INTEGER,

amount INTEGER
)

Giả sử có một bảng có một chỉ mục theo cột color. Hai truy vấn sau đây minh họa
việc sử dụng dấu tham số có thể tạo nên sự khác biệt hiệu năng lớn khi làm việc
với bảng này:
SELECT price, amount
FROM toyLists
WHERE color = 'PINK'
AND type = 'CAR'



SELECT price, amount
FROM toyLists
WHERE color = 'BROWN'
AND type = 'CAR'

Trong truy vấn đầu tiên, thu được 800.000 bản ghi với màu Hồng ('PINK'). Danh
sách này sau đó sẽ được làm giảm hơn nữa dựa vào có bao nhiêu đồ chơi màu
hồng là loại 'CAR'. Có thể nghĩ quét đơn giản toàn bộ bảng thay vì sử dụng chỉ
mục, vì rất nhiều bản ghi sẽ được trả về.
Ví dụ thứ hai trả về chỉ năm bản ghi dựa trên màu Nâu ('BROWN'), và có thể có ít
hơn số đó vì nó thu hẹp việc tìm kiếm của mình cho kiểu 'CAR'. Tôt nhất là sử
dụng chỉ mục về màu sắc (color) để làm giảm số các mục cần tìm đối với kiểu
'CAR'.
Bây giờ, hãy xem xét những gì sẽ xảy ra nếu một truy vấn tương tự được gửi đi
khi sử dụng một dấu tham số:
SELECT price, amount
FROM toyLists

WHERE color = ?
AND type = 'CAR'

Trong trường hợp này, DB2 không có ý tưởng về những màu nào phải được lấy ra.
Nó không biết 5 hoặc 300.000 bản ghi sẽ được trả về. Nếu một giá trị mầu sắc
thực tế đã được sử dụng, một kế hoạch truy cập hoàn toàn khác có thể được chọn.
Khi cần các dấu tham số, DB2 sử dụng các số liệu thống kê trung bình về cột để
tạo ra một kế hoạch truy cập. DB2 xác định trung bình bao nhiêu bản ghi mỗi màu
có được. Do 'PINK' là quá phổ biến, số lượng bản ghi trung bình cho màu sẽ khá
cao và vì thế DB2 có lẽ sẽ quét bảng cho mọi truy vấn mà ở đó màu sắc được sử
dụng như vị từ. Điều này sẽ là tốt cho các truy vấn lọc màu hồng ('PINK'), nhưng
là xấu cho các màu 'RED' hay 'BROWN'. Trong hai trường hợp sau, nó có thể tốt
hơn nếu một dấu tham số đã không được sử dụng trong truy vấn, vì thời gian dịch
thêm không đáng so với thời gian xử lí vượt trội gây nên do việc quét bảng.


Khi nào sử dụng các dấu tham số
Có một số các tình huống mà các dấu tham số có thể cải thiện hiệu năng ứng dụng
của bạn. Bạn nên dùng dấu tham số trong:
 Các truy vấn được thực hiện nhiều lần và chỉ thay đổi các giá trị tham số
của chúng.
 Các truy vấn có thời gian biên dịch có thể được kéo dài hơn thời gian thực
hiện.
 Tóm lại, các truy vấn giống như OLTP.
Tuy nhiên, có một số truy vấn không lợi nhiều khi sử dụng các dấu tham số:
 Các truy vấn được thực hiện một lần và các giá trị của tham số của nó luôn
luôn giống nhau
 Các truy vấn lớn, giống như OLAP ở đó thời gian biên dịch là một phần
của tổng thời gian thực hiện.
 Các truy vấn mà trong đó các giá trị của các biến có tác động lớn đến cách

tạo ra kế hoạch truy cập SQL.
 Các truy vấn trong đó các giá trị dấu tham số có thể có liên quan và cần đến
DB2 có khả năng nhận dạng một mẫu hoặc phân bố dữ liệu từ các số liệu
thống kê, ví dụ như các cặp thành phố - bang hoặc các cặp năm- tháng.
 Các truy vấn có thể chạy dựa vào các tập dữ liệu với các sự phân bố không
đồng nhất, bởi vì việc sử dụng các dấu tham số có thể làm cho trình tối ưu
của DB2 bỏ phân bố thỗng kế đối xứng lệch quan trọng đối với các giá trị
nhất định
May thay, có những cải tiến mới trong DB2 9 cho Linux, UNIX và Windows để
cho phép bạn tác động đến hành vi tối ưu hóa câu truy vấn mặc định, có nghĩa là
một số trong những bất lợi nêu trên không phải là phổ biến. Để biết thêm thông
tin, tham khảo bài viết có tựa đề "Tác động tối ưu hóa truy vấn với các mô tả sơ
lược về tối ưu hóa và các khung nhìn thống kê trong DB2 9" trong phần Tài
nguyên của tài liệu này.


SQL ghép
Khi nào sử dụng SQL ghép
Bình thường, các câu lệnh SQL được thực hiện riêng rẽ. Điều này cho phép dễ lập
trình, nhưng nó cũng có nghĩa là mỗi câu lệnh và tập kết quả phải được truyền đi
giữa máy khách và máy chủ mỗi lần. Để giảm lưu lượng mạng mà ứng dụng của
bạn tạo ra, bạn có thể nhóm một số các câu lệnh SQL vào một nhóm đơn. Nhóm
này được gọi là SQL ghép. SQL ghép thường được sử dụng trong các đối tượng
phía máy chủ như các thủ tục tạo sẵn và các hàm do người dùng định nghĩa, cũng
như trong các ứng dụng SQL nhúng.
Có hai kiểu của SQL ghép: nguyên tử và không nguyên tử.
Với SQL nguyên tử, ứng dụng nhận được trả lời từ người quản trị cơ sở dữ liệu
khi tất cả các câu lệnh bao quanh của nó đã thực hiện thành công hay khi một
trong các câu lệnh con bao quanh không thực hiện thành công. Nếu câu lệnh con
không thực hiện thành công, toàn bộ khối này được coi là bị hỏng và bất kỳ thay

đổi nào được thực hiện cho cơ sở dữ liệu trong khối đó được khôi phục lại.
Với SQL không nguyên tử, ứng dụng nhận được trả lời từ người quản trị cơ sở dữ
liệu khi tất cả các câu lệnh con bao quanh đã thực hiện thành công. Mỗi câu lệnh
con trong một khối được thi hành bất kể câu lệnh con trước đó đã thực hiện thành
công hay không. Nhóm các câu lệnh chỉ có thể được khôi phục nếu đơn vị công
việc có chứa các SQL ghép không nguyên tử được khôi phục.


SQL ghép: Thuận lợi và khó khăn

×