Di chuyển một ứng dụng PHP từ MySQL sang DB2, Phần 3: Chuyển đổi mã PHP của bạn

Chia sẻ: Nhung Nhung | Ngày: | Loại File: PDF | Số trang:22

Thêm vào BST

Báo xấu

54
lượt xem 7
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tham khảo tài liệu 'di chuyển một ứng dụng php từ mysql sang db2, phần 3: chuyển đổi mã php của bạn', công nghệ thông tin, cơ sở dữ liệu phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Di chuyển một ứng dụng PHP từ MySQL sang DB2, Phần 3: Chuyển đổi mã PHP của bạn

Di chuyển một ứng dụng PHP từ MySQL sang DB2, Phần 3: Chuyển đổi mã PHP của bạn Giới thiệu về loạt bài này MySQL hiện là máy chủ cơ sở dữ liệu phổ biến nhất được sử dụng với ngôn ngữ lập trình PHP để xây dựng các ứng dụng web động. Tuy nhiên, DB2 là một cơ sở dữ liệu phổ biến khác được PHP hỗ trợ đầy đủ và cung cấp các lợi thế hấp dẫn hơn so với MySQL, làm cho nó trở thành một sự lựa chọn lý tưởng cho nhiều ứng dụng. Loạt bài này mô tả tại sao việc di chuyển một ứng dụng PHP sang DB2 lại có ý nghĩa, cách chuẩn bị cho việc di trú, cách thực hiện nó, cách hỗ trợ nó, và cách xử lý các rủi ro tiềm năng dựa trên kinh nghiệm của các tác giả cho một cuộc di trú mới nhất. Nhiều mẫu mã và mẫu cấu hình được cung cấp, cũng như các chỉ dẫn tài nguyên để giúp cho dự án chạy trơn tru. Với các ví dụ và các bài học thu được từ một việc chuyển đổi thực tế thành công, bạn sẽ thấy đây có thể là một dự án đơn giản, có đủ tài liệu và cung cấp các lợi ích hấp dẫn. Loạt bài bốn phần này chia sẻ các bài học nhận được từ cuộc di trú MySQL-sang-DB2 thành công cho một ứng dụng mạng nội bộ PHP trọng yếu, cấp độ sản xuất, được 4.000 người dùng toàn cầu trong IBM sử dụng để hỗ trợ sản xuất nội dung cho ibm.com.  Phần 1 mô tả các bước cần thực hiện để chuẩn bị cho việc di trú.  Phần 2 mô tả các bước cần thực hiện để di trú cơ sở dữ liệu.  Phần 3 mô tả các bước cần thực hiện để chuyển đổi mã PHP.  Phần 4 mô tả các bước cần thực hiện để triển khai và hỗ trợ ứng dụng. Bạn sẽ học được những gì Mục đích của loạt bài này là cho bạn hiểu những gì thường cần thiết để di trú một ứng dụng PHP từ MySQL sang DB2, những tài nguyên nào có sẵn để trợ giúp bạn và một nhóm dự án của IBM đã thực hiện nhiệm vụ này vào đầu năm 2010 như thế nào. Nếu bạn đã nghiên cứu một cuộc di trú từ MySQL sang DB2, bạn có thể đã thấy những giá trị mà DB2 cung cấp dựa trên tài liệu sản phẩm, các đánh giá tiêu chuẩn về hiệu năng, các tính năng mà bạn đã đọc trong tài liệu DB2, hoặc các so sánh trong các Sách Đỏ của IBM (IBM Redbooks ®) dành riêng cho nhiệm vụ này, bao gồm cuốn Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên ). Bạn có lẽ cũng biết rằng DB2 Express-C là một máy chủ dữ liệu quan hệ có đủ chức năng, miễn phí có thể dễ dàng được cài đặt hoặc được đánh giá bằng cách sử dụng IBM SmartCloud (tên cũ là Development and Test on the Cloud - Phát triển và Thử nghiệm trên Đám mây của IBM) hoặc Amazon EC2. Các liên kết đến các tài nguyên này có sẵn trong phần Tài nguyên.
Loạt bài này cung cấp cho bạn một ví dụ cụ thể về cuộc di trú thực tế đã được thực hiện thành công như thế nào trong năm 2010 cho một ứng dụng mạng nội bộ PHP được sử dụng rất nhiều trong IBM để hỗ trợ quản lý nội dung hàng ngày được công bố trên nhiều phần của trang Web ibm.com. Sau khi bạn đọc xong loạt bài này, bạn sẽ có thể tạo một trường hợp di trú tương tự, hiểu được thời hạn và các phụ thuộc của các mục công việc cần được thực hiện, dự kiến các rủi ro tiềm năng, và biết nơi để tìm kiếm sự hỗ trợ từng bước trên đường đi. Tất cả điều này sẽ cho bạn sự tự tin hơn để lựa chọn DB2 và sử dụng nó một cách tốt nhất cho các ứng dụng PHP của bạn hiện đang được phát triển trên MySQL. Những gì không trình bày Loạt bài này nhằm chia sẻ các bài học thu được từ một cuộc di trú nội bộ IBM từ MySQL sang DB2 và cung cấp cho bạn thông tin về tài nguyên có sẵn để thực hiện một công cuộc tương tự. Loạt bài này không phải là một hướng dẫn toàn diện về di trú để có thể áp dụng được cho tất cả các kịch bản. Để xác định một cách tiếp cận phù hợp với bạn, hãy tham khảo Hướng dẫn chuyển đổi MySQL sang DB2 hoặc liên hệ với SMPO (Software Migration Project Office - Văn phòng dự án di trú phần mềm) để đánh giá di trú miễn phí. Các liên kết này được cung cấp trong phần Tài nguyên. Về đầu trang Giới thiệu về việc di trú mã Bài này trình bày năm bước làm việc chính trong một nghiên cứu chi tiết để thực hiện di trú mã ứng dụng PHP từ chỗ đang sử dụng các trình điều khiển và cú pháp MySQL tới chỗ làm việc với DB2. Nếu cần, hãy tham khảo Phần 1 của loạt bài này để xem lịch trình các bước ấy trong quá trình di trú tổng thể trước khi tiến hành chuyển đổi. Bước 1: Bắt đầu bước chuyển đầu tiên trong di trú mã  Đảm bảo cập nhật cấu hình PHP để hỗ trợ DB2.  Cập nhật các câu lệnh SQL riêng lẻ để hỗ trợ cú pháp DB2.  Mô phỏng các hàm MySQL nguyên gốc bằng cách sử dụng các hàm DB2 do người dùng định nghĩa, nếu cần.  Di chuyển logic xử lý từ SQL vào PHP, nếu cần. Bước 2: Bắt đầu bước chuyển thứ hai trong di trú mã  Xem xét các thay đổi cần thiết để hỗ trợ các mức cách ly thích hợp.  Tổ chức lại các truy vấn thành các đơn vị công việc logic để đạt được tính toàn vẹn dữ liệu tốt hơn và cải thiện hiệu năng. Bước 3: Bắt đầu thử nghiệm trường hợp sử dụng nghiệp vụ khởi đầu với các bên liên quan
 Phối hợp các bên liên quan để thực hiện các trường hợp sử dụng đã quen thực hiện trong hệ thống cũ.  Nắm bắt các thất bại kiểm thử như là các khiếm khuyết cần được các nhà phát triển phân tích và sửa chữa. Bước 4: Giải quyết nút nghẽn cổ chai và xác nhận dựa vào vạch chuẩn chức năng  Cải thiện hiệu năng của hệ thống dựa vào sự phản hồi của người dùng sau khi kiểm tra chức năng.  Tập trung vào những gì DB2 có thể sửa chữa tự động cho bạn, vì DB2 là sự thay đổi lớn nhất mà bạn đưa vào.  Giải quyết nút nghẽn cổ chai PHP bằng cách xem xét cách sử dụng tài nguyên của hệ điều hành. Bước 5: Đánh giá vạch chuẩn di trú mã  Sau khi hoàn thành theo cách lặp lại các bước trên, khai báo hoàn thành việc chuyển đổi mã.  Sao lưu hệ thống và gắn thẻ mốc quan trọng trong hệ thống kiểm soát mã nguồn của bạn.  Đánh giá mức độ chuẩn bị cần thiết cho nhiệm vụ tiếp theo: triển khai ứng dụng. Về đầu trang Tìm hiểu nghiên cứu chi tiết về ví dụ cơ sở mã PHP của PTT hiện có Nhắc nhở Nếu cần, hãy tự mình tìm hiểu phần Tài nguyên có thể giúp ích trong việc di trú của bạn. Các tài nguyên sau có thể đặc biệt có ích cho bước này:  Chương 8 và 10 trong Sách Đỏ miễn phí của IBM (IBM Redbook ®) Hướng dẫn chuyển đổi MySQL sang DB2.  Chương 4 và 6 trong Sách Đỏ miễn phí của IBM Phát triển các ứng dụng PHP cho Các máy chủ dữ liệu IBM.  Bài viết trên developerWorks "Danh sách khuyến khích đọc: Phát triển ứng dụng DB2 cho Linux, UNIX, và Windows".  Các mục blog của Daniel Krook về kinh nghiệm cá nhân của ông trong một dự án di trú cho một ISV. Tất nhiên các tài liệu về ngôn ngữ lập trình PHP và phần mở rộng của trình điều khiển DB2 cũng là các phương tiện cần thiết. Một lựa chọn khác là sử dụng đám mây cho quá trình di trú. Bạn có thể sử dụng Linux EC2 của Amazon và các AMI của DB2, hoặc đăng ký dùng IBM SmartCloud (tên cũ là Development and Test on the Cloud - Phát triển và Thử nghiệm trên Đám mây của IBM)(xem phần Tài nguyên ).
Với ứng dụng ví dụ trong bài này, mã nguồn cho Project Tracking Tool (PTT - Công cụ theo dõi dự án) bao gồm hàng trăm tệp PHP. Cơ sở mã có các thư viện hàm, mã hướng-đối tượng được tổ chức thành các đối tượng truyền dữ liệu và các lớp của trình quản lý, các đoạn khuôn mẫu HTML khác nhau và các trình trợ giúp để biểu hiện giao diện người dùng. Cơ sở dữ liệu PTT được sử dụng với các hàm khác nhau để hỗ trợ luồng công việc cung cấp thông tin được công bố trên ibm.com. Hơn 4.000 người dùng trên toàn thế giới truy cập và sửa đổi cơ sở dữ liệu PTT thông qua mặt tiền web PHP. Tại bất kỳ thời điểm nào, đều có hàng trăm người dùng đang hoạt động đồng thời trên hệ thống. Mã này được triển khai vào một máy chủ web Apache, nó nạp tệp mod_php như là một mô đun chia sẻ. Trong ví dụ này, mã hiện có đã được cập nhật cho hệ thống DB2 mới, chủ yếu là bằng cách thực hiện các sửa đổi với SQL nhúng. Các sửa đổi nhỏ khác bắt buộc phải làm là cập nhật cấu hình PHP để sử dụng trình điều khiển DB2 và điều chỉnh mã kết nối cơ sở dữ liệu, sử dụng một chuỗi kết nối mới. Bài này cũng xác định và tập trung vào một số cải tiến cấu trúc ứng dụng để hoàn thiện hơn khung kiến trúc mô hình-khung nhìn-trình điều khiển (MVC) nhằm cải tiến chất lượng, tổ chức và bảo trì ứng dụng. Về đầu trang Cài đặt phần mềm chuyển đổi Để chuẩn bị cho việc chuyển đổi mã ví dụ, hãy cài đặt các thành phần sau đây trên một máy trạm Windows được sử dụng để thực hiện các bước chuyển đổi. Một phiên bản của bản sao MySQL của cơ sở dữ liệu nguồn Để kiểm tra mỗi thay đổi mã, điều quan trọng là có một bản sao của hệ thống cũ sẵn sàng để sử dụng làm một tham chiếu chức năng để xác nhận hợp lệ các thay đổi cho hệ thống mới bên cạnh hệ thống cũ. Bạn có thể sử dụng chính hệ thống như bạn đã làm trong Phần 2. Một phiên bản DB2 với các trình điều khiển máy chủ dữ liệu được cài đặt cục bộ hoặc trên một máy chủ thử nghiệm Cài đặt DB2 để tạo cơ sở dữ liệu đích mới trên máy trạm. Nói chung, cơ sở dữ liệu này không nhất thiết là ấn bản giống như cơ sở dữ liệu được sử dụng trong sản xuất, nhưng để tương thích tính năng hoàn toàn, một ý tưởng tốt là nên chọn cùng ấn bản. Để làm theo các ví dụ trong bài này, hãy cài đặt Ấn bản máy chủ doanh nghiệp của DB2 (DB2 Enterprise Server Edition) Phiên bản 9.7.2. Đảm bảo rằng các trình điều khiển của máy chủ dữ liệu có sẵn để cung cấp các thư viện khách PHP cần thiết. Bạn có thể sử dụng chính hệ thống như bạn đã làm trong Phần 2. Một phiên bản PHP được xây dựng với phần mở rộng ibm_db2 hoặc PDO_IBM (PHP Data Objects) Tải về phiên bản mới nhất của Zend Server và chọn phần mở rộng DB2 tùy chọn, có yêu cầu cài đặt các gói bổ sung.
Một môi trường phát triển tích hợp (IDE), ví dụ Zend Studio hoặc Các công cụ phát triển PHP (PDT) của Eclipse Sử dụng một IDE nhận biết-PHP, ví dụ Zend Studio hoặc Các công cụ phát triển PHP của Eclipse, để dễ dàng phát triển PHP của bạn. Vì bạn duy trì một ứng dụng PHP, nên nhiều khả năng là bạn đã có một công cụ ưa thích. Hãy chắc chắn ghi lại chi tiết các quyết định cấu hình và các bài học thu được của bạn để cho bạn có thể lặp lại các bước khi triển khai. Xem xét việc ghi lưu một ảnh chụp của hệ điều hành Windows thành một ảnh ảo tại các cột mốc chính mỗi khi đạt được các đích quan trọng để dùng làm các bản sao lưu cấu hình và các vạch chuẩn để so sánh cải thiện tiếp mã lệnh. Nếu bạn muốn chụp một ảnh của một cấu hình máy tính vật lý, bạn có thể làm điều đó bằng VMware vCenter Converter miễn phí. Một cách thay thế khác là xem xét dùng đám mây cho các thay đổi năng động này. Bạn có thể sử dụng các AMI DB2 cho EC2 của Amazon, hoặc bạn có thể đăng ký dùng IBM SmartCloud (tên cũ là Development and Test on the IBM Cloud). Với các máy tính ảo, bạn sẽ có thể tránh được các cố gắng ban đầu để mua phần cứng máy chủ và cài đặt một hệ điều hành và DB2, điều này sẽ tiết kiệm thời gian, tăng tốc độ di trú, và mang lại cho bạn sự tự tin để trải nghiệm với cấu hình phù hợp nhất cho các nhu cầu của bạn. Có thể tìm thấy các liên kết đến tất cả các sản phẩm này trong phần Tài nguyên. Về đầu trang Bước 1: Bắt đầu một bước chuyển đầu tiên về di trú mã Bước chuyển đổi mã quan trọng đầu tiên là cấu hình cơ sở hạ tầng PHP và DB2 mới và chuyển đổi cách ứng dụng sử dụng PHP và SQL để truy cập dữ liệu. Bước này liên quan đến các bước nhỏ sau:  Cập nhật cấu hình và trình điều khiển PHP.  Chuyển đổi cú pháp SQL.  Tạo các hàm do người dùng định nghĩa để mô phỏng MySQL.  Di chuyển logic từ SQL vào PHP, nếu cần. Cập nhật cấu hình và trình điều khiển PHP Đảm bảo rằng cấu hình PHP hiện có được sửa đổi để hỗ trợ trình điều khiển của DB2, để khớp với bộ mã hóa ký tự cơ sở dữ liệu máy chủ và để cung cấp các thông báo chẩn đoán quan trọng thông qua cảnh báo và các thông báo lỗi đầy đủ mọi chi tiết. Để cập nhật mã PHP cho DB2, bạn sẽ thường thay đổi từng điểm trong mã ở đó các hàm mở rộng ibm_db2 được sử dụng hoặc cập nhật chuỗi kết nối PDO_IBM để thực hiện giao diện PDO (Các đối tượng dữ liệu PHP). Nếu bạn sử dụng PDO như một thư viện trừu tượng hóa cơ sở dữ liệu trong hệ thống dựa trên MySQL của mình, các thay đổi mã của bạn sẽ không đáng kể. Đó chỉ là vấn đề thay đổi một chuỗi kết nối duy nhất. Nhưng cho dù là bạn đang sử dụng phần mở rộng thủ tục ibm_db2, nhiệm vụ này cũng đơn giản. Bạn có thể thay thế bình thường bất kỳ các hàm nào bắt đầu với mysql_ hoặc mysqli_ trong mã của bạn bằng các tiền tố db2_ tương đương.
Xem phần 6.3 Chương 6 về Phát triển các ứng dụng PHP cho các máy chủ dữ liệu của IBM trong Sách Đỏ của IBM (xem phần Tài nguyên) để biết các bảng ánh xạ tương ứng các hàm và mã mẫu. Cả hai phương thức kết nối đều dựa vào máy khách DB2 làm một cầu nối để nối đến máy chủ DB2, vì vậy bạn cần xác nhận rằng máy khách DB2 đã được cấu hình khớp với các thiết lập trên máy chủ từ xa. Cụ thể, bạn cần đảm bảo chắc chắn rằng trang mã ký tự của máy khách DB2 giống như trang mã ký tự của máy chủ DB2, nếu không, bạn sẽ gặp khó khăn với các bộ ký tự. Với ví dụ này, hãy chạy lệnh được hiển thị trong Liệt kê 1 để thiết lập bộ mã hóa ký tự máy khách là UTF-8, sẽ phù hợp với lệnh CREATE DATABASE trong Liệt kê 1 trong Phần 2. Liệt kê 1. Thiết lập trang mã máy khách DB2 thành UTF-8 db2set db2codepage=1208 Để đảm bảo thiết lập này được sử dụng trên mỗi máy trạm hoặc các máy chủ mà bạn cài đặt máy khách thời gian chạy, hãy chạy lệnh trong Liệt kê 2. Liệt kê 2. Xem các biến cấu hình của DB2 db2set -all Cuối cùng, trong quá trình phát triển, sẽ rất có ích nếu đảm bảo rằng tất cả các thông báo và các cảnh báo lỗi được thu giữ và được hiển thị trong trình duyệt. Trong tệp php.ini của bạn, hãy cập nhật các tham số được hiển thị trong Liệt kê 3. Hãy nhớ đặt chúng trở lại các thiết lập ít dài dòng hơn khi bạn chuyển sang sản xuất. Phần 4 của loạt bài này cung cấp một ví dụ về một cơ chế báo cáo lỗi thích hợp hơn để sử dụng khi bạn triển khai vào sản xuất. Liệt kê 3. Thiết lập các tham số kiểm soát lỗi trong php.ini display_errors = On error_reporting = E_ALL & ~E_NOTICE Chuyển đổi cú pháp SQL Tiếp theo, hãy cập nhật các câu lệnh SQL riêng lẻ để hỗ trợ cú pháp DB2 hoặc thay đổi chúng để truy cập dữ liệu theo cách hơi khác một chút để đạt được kết quả tương tự. Đối với hầu hết các ứng dụng, bước này cần rất nhiều lần cập nhật mã và kiểm tra thử nghiệm. Tham khảo Chương 8.1 các điểm giống nhau và khác nhau của Ngôn ngữ thao tác dữ liệu trong Sách Đỏ Hướng dẫn chuyển đổi MySQL sang DB2 để xem một danh sách các phép chuyển đổi cú pháp phổ biến. Sau đây là một vài tình huống trong ứng dụng nghiên cứu chi tiết.
Cách xử lý ký tự đại diện của mệnh đề SELECT Các câu lệnh SELECT sử dụng một ký tự đại diện (ký tự dấu hoa thị) để chọn cột cụ thể bên cạnh tất cả các cột của nhiều bảng là hợp pháp trong MySQL, nhưng chúng lại không được phép trong DB2. Trong trường hợp này, thêm tên bảng (hoặc bí danh) đầy đủ vào trước ký tự đại diện, chỉ rõ mỗi cột của mỗi bảng mà bạn đang quan tâm đến hoặc đơn giản là liệt kê tất cả các cột trong mỗi bảng với một ký tự đại diện duy nhất. Liệt kê 4 cho thấy cách sửa đổi các truy vấn như vậy. Liệt kê 4. So sánh các ký tự đại diện của cột và bảng hợp pháp trong MySQL và DB2 -- In MySQL: SELECT R.NAME, * FROM USER U, ROLE R WHERE U.ROLE_ID = R.ID; -- In DB2: SELECT R.NAME, U.* FROM USER U, ROLE R WHERE U.ROLE_ID = R.ID; -- Or SELECT R.NAME, U.ID, U.NAME, U.ROLE_ID, U.DEPART_ID FROM USER U, ROLE R WHERE U.ROLE_ID = R.ID; Mệnh đề SELECT quy định cụ thể kích thước tối đa của tập kết quả với LIMIT LIMIT (Giới hạn) là một từ khóa không chuẩn, chỉ duy nhất của MySQL quy định cụ thể số lượng tối đa các hàng được trả về từ một truy vấn. DB2 sử dụng cú pháp FETCH FIRST n ROWS ONLY cho cùng một mục đích. Liệt kê 5 cho bạn thấy cách viết lại truy vấn với DB2. Liệt kê 5. Quy định số lượng tối đa các hàng được trả về từ một truy vấn trong MySQL và DB2 -- In MySQL: SELECT * FROM ROLE LIMIT 10; -- In DB2: SELECT * FROM ROLE FETCH FIRST 10 ROWS ONLY; Mệnh đề GROUP BY MySQL cho phép sử dụng một mệnh đề GROUP BY không chỉ rõ từng tên cột không được sử dụng bởi một hàm tổng hợp trong danh sách cột. Nhưng trong DB2, điều này là không hợp lệ, vì tập kết quả có thể có mức mơ hồ không thể chấp nhận được đối với nhiều người sử dụng. Liệt kê 6 cho thấy cách quy định rõ các cột trong truy vấn với DB2. Liệt kê 6. So sánh các phép gộp GROUP BY hợp pháp trong MySQL và DB2 -- In MySQL: SELECT R.ID, R.NAME, COUNT(U.ID) AS NUM FROM USER U, ROLE R
WHERE U.ROLE_ID = R.ID GROUP BY R.ID; -- In DB2: SELECT R.ID, MIN(R.NAME), COUNT(U.ID) AS NUM FROM USER U, ROLE R WHERE U.ROLE_ID = R.ID GROUP BY R.ID; -- Or SELECT R.ID, R.NAME, COUNT(U.ID) AS NUM FROM USER U, ROLE R WHERE U.ROLE_ID = R.ID GROUP BY R.ID, R.NAME; Trong Liệt kê 6, bạn có thể cập nhật GROUP BY, vì cả hai R.ID và R.NAME là khóa duy nhất trong bảng này. Liệt kê 7 cho thấy một loại truy vấn GROUP BY khác không thể xử lý đơn giản như truy vấn trong Liệt kê 6. Liệt kê 7. GROUP BY không rõ ràng trong MySQL cần được sửa đổi cho DB2 -- In MySQL: SELECT R.ID, R.NAME, COUNT(U.ID) AS NUM FROM USER U, ROLE R WHERE U.ROLE_ID = R.ID GROUP BY R.NAME; Trong trường hợp này, R.ID là duy nhất trong bảng, nhưng R.NAME thì không. Nếu có bản sao giá trị R.NAME trong bảng ROLE, thì bạn không thể thay thế R.ID bằng MIN(R.ID) và bạn không thể thêm R.ID vào mệnh đề GROUP BY. Cách bạn chuyển đổi SQL này như thế nào phụ thuộc vào bạn mong đợi kết quả dạng nào. Liệt kê 8 cho thấy một vài tùy chọn cho tình huống này. Liệt kê 8. Truy vấn GROUP BY đã dịch trong DB2 -- In DB2: -- Option 1, if you want to get same result as what you get in MySQL, the SQL is: SELECT (SELECT RL.ID FROM ROLE RL WHERE RL.NAME = R.NAME FETCH FIRST 1 ROW ONLY) AS ID, R.NAME, COUNT(U.ID) AS NUM FROM USER U, ROLE R WHERE U.ROLE_ID = R.ID GROUP BY R.NAME; -- Option 2, if role name is same, treat it as same role. In this case, -- the result is a little different from MySQL version in that there is no R.ID: SELECT R.NAME, COUNT(U.ID) AS NUM
FROM USER U, ROLE R WHERE U.ROLE_ID = R.ID GROUP BY R.NAME; -- Option 3, if role ID is different, treat them as different role. -- In this case, the result is totally different than the MySQL version: SELECT R.ID, R.NAME, COUNT(U.ID) AS NUM FROM USER U, ROLE R WHERE U.ROLE_ID = R.ID GROUP BY R.ID, R.NAME; REPLACE INTO trong MySQL so với MERGE trong DB2 MySQL cung cấp một mệnh đề REPLACE INTO. DB2 cung cấp một mệnh đề MERGE cho một mục đích tương tự, nhưng không tương đương. Để đạt được kết quả tương đương, hãy tạo ra một bản ghi mới hoặc thay thế một bản ghi hiện có nếu nó có khóa chính giống nhau hoặc giá trị duy nhất. Liệt kê 9 cho thấy cách kiểm tra một giá trị duy nhất trong bảng và hoặc cập nhật hoặc chèn các giá trị. Liệt kê 9. Dịch cú pháp REPLACE INTO của MySQL sang DB2 -- In MySQL: REPLACE INTO ROLE (ID, NAME, DESCRIPTION) SELECT ID, NAME, DESCRIPTION FROM ROLE_TMP; -- In DB2: MERGE INTO ROLE R USING (SELECT ID, NAME, DESCRIPTION FROM ROLE_TMP) RT ON (R.ID = RT.ID) WHEN MATCHED THEN UPDATE SET (ID, NAME, DESCRIPTION) = (RT.ID, RT.NAME, RT.DESCRIPTION) WHEN NOT MATCHED THEN INSERT (ID, NAME, DESCRIPTION) VALUES (RT.ID, RT.NAME, RT.DESCRIPTION); Mệnh đề JOIN Khi thực hiện một phép nối (join) ngoài với một cặp bảng đồng thời cũng lấy ra dữ liệu từ một bảng thứ ba, hãy chỉ rõ các bảng được sử dụng cho phép nối ngoài kề ngay bên cạnh các từ khóa JOIN trong DB2. MySQL cho phép chúng được liệt kê theo bất kỳ thứ tự nào. Liệt kê 10 cho thấy sự thay đổi cần thiết. Liệt kê 10. So sánh cú pháp JOIN của MySQL và DB2 -- Both of the following work in MySQL: SELECT * FROM USER U, ROLE R LEFT JOIN DEPARTMENT D ON U.DEPT_ID = D.ID; -- Or SELECT * FROM ROLE R, USER U LEFT JOIN DEPARTMENT D ON U.DEPT_ID = D.ID;
-- Only this one works in DB2: SELECT * FROM ROLE R, USER U LEFT JOIN DEPARTMENT D ON U.DEPT_ID = D.ID; Các ký tự thoát Ký tự \ biểu diễn một dấu gạch chéo ngược là mã thoát áp dụng cho dấu nháy đơn ' trong MySQL, nhưng trong DB2, một dấu nháy đơn phải được áp mã thoát bằng cách thêm một dấu nháy đơn khác " (hai dấu nháy đơn). Liệt kê 11 cho thấy một ví dụ về các dãy mã thoát cho một chuỗi ký tự sử dụng một dấu nháy đơn như là một dấu móc lửng. Liệt kê 11. MySQL sử dụng dấu gạch chéo ngược để áp mã thoát cho các dấu nháy đơn, trong khi ở đó DB2 sử dụng một dấu nháy đơn thứ hai -- In MySQL: SELECT * FROM ROLE WHERE DESCRIPTION = 'It\'s a super admin role'; -- In DB2: SELECT * FROM ROLE WHERE DESCRIPTION = 'It''s a super admin role'; Kiểm tra ngoài phạm vi trong DB2 MySQL không bắt buộc đúng phạm vi cho một kiểu dữ liệu trong một mệnh đề SELECT, nhưng DB2 thì có. Do đó SQL được hiển thị trong Liệt kê 12 để truy vấn thông tin trong khoảng thời gian từ 01.02 và 30.02 không làm việc trong DB2, nhưng nó làm việc trong MySQL. Liệt kê 12. MySQL không kiểm tra dải các giá trị cho các mệnh đề WHERE dựa vào kiểu dữ liệu -- MySQL allows you to specify February 30th as part of the range SELECT * FROM USER WHERE BIRTHDAY BETWEEN '1980-02-01' AND '1980-02-30'; CHÈN vào một cột NOT NULL không cần một giá trị mặc định Trong MySQL, nếu bạn cố gắng thực hiện một câu lệnh INSERT mà không cung cấp một giá trị cho một cột NOT NULL, thì lệnh này vẫn thành công. MySQL tự động điền vào một giá trị mặc định, ngay cả khi bạn chưa bao giờ định nghĩa một giá trị mặc định cho cột đó khi tạo bảng. Tuy nhiên, trong DB2, bạn phải cung cấp một giá trị cho các cột NOT NULL trong một câu lệnh INSERT khi vẫn chưa đinh nghĩa một giá trị mặc định. Các câu lệnh SQL trong Liệt kê 13 cho thấy các hành vi xử lý khác nhau. Liệt kê 13. MySQL và DB2 xử lý chèn các giá trị NULL một cách khác nhau -- Works in both MySQL and DB2 CREATE TABLE TEST1 (ID INTEGER, NAME VARCHAR(20) NOT NULL); -- Works in MySQL, doesn't work in DB2 INSERT INTO TEST1 (ID) VALUES(1);
-- Works in both MySQL and DB2 CREATE TABLE TEST2 (ID INTEGER, NAME VARCHAR(20) NOT NULL DEFAULT ''); -- Works in both MySQL and DB2 INSERT INTO TEST2 (ID) VALUES(1); Sử dụng các chế độ tương thích mới của DB2 Trong khi bạn có thể mô phỏng một số cú pháp MySQL bằng cách sử dụng các hàm do người dùng định nghĩa, có một lựa chọn khác là thiết lập một trong các chế độ tương thích dành cho các phiên bản của DB2 sau phiên bản 9.7.2. Đọc thêm về kích hoạt cú pháp LIMIT và OFFSET trên blog của Antonio Cangiano. Chuyển đổi các hàm của MySQL thành các hàm tương tự của DB2 Bên cạnh SQL đặc thù riêng của MySQL, bạn cũng có thể đang sử dụng các hàm MySQL dựng sẵn. Bạn có thể thay thế các hàm này bằng các hàm SQL tiêu chuẩn hoặc các hàm tương đương có sẵn trong DB2. Tham khảo Phụ lục A: Ánh xạ các hàm dựng sẵn và các toán tử của MySQL trong Sách Đỏ Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên). Như vừa được mô tả, nếu bạn không thể tìm thấy một hàm tương đương của DB2, thì bạn có thể viết lại SQL của mình để truy cập dữ liệu theo một cách khác. Ngoài ra, bạn có thể chọn mô phỏng hàm đó trong DB2 hoặc di chuyển logic vào mã PHP của mình, như được mô tả trong các phần sau. Tạo các hàm do người dùng định nghĩa để mô phỏng các tính năng của MySQL Nếu bạn không thể chỉ cập nhật các câu lệnh SQL theo cú pháp DB2 để đạt được cùng kết quả như các truy vấn MySQL của bạn, thì bạn có thể khắc phục bằng một cách khác dưới dạng một hàm do người dùng định nghĩa (UDF) trong SQL của DB2 để mô phỏng một hàm MySQL dựng sẵn. Đã có một số chỗ sử dụng MySQL và PHP trong kịch bản ví dụ cần được tiếp cận theo cách khác khi cập nhật ứng dụng để sử dụng DB2. Cụ thể, bạn có thể di chuyển một số chức năng ra khỏi MySQL đưa vào PHP, ví dụ như khi thực hiện chuyển dịch ngày. Hoặc bạn có thể mô phỏng hàm trong DB2, ví dụ như để tạo các hàm do người dùng định nghĩa trong DB2 cho gần giống một số hàm được xây dựng trong MySQL, bao gồm cả UNIX_TIMESTAMP() và NOW(). Phụ lục B trong Sách Đỏ Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên) giải thích các sự khác biệt và đưa ra một cách tiếp cận để giải quyết các thay đổi. Những mẹo nhỏ của Daniel Krook đã thu thập được từ kinh nghiệm di trú của khách hàng của ông cũng rất có ích (xem phần Tài nguyên). DML của DB2 khác với MySQL. Bài này mô tả cách chuyển đổi các SQL nhúng từ MySQL sang DB2. Tuy nhiên, không cần thiết chuyển đổi tất cả cú pháp từ MySQL sang DB2, đặc biệt là đối với các hàm dựng sẵn của MySQL. Phụ lục A. Ánh xạ các hàm dựng sẵn và các toán tử
của MySQL trong Sách Đỏ Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên) liệt kê rất nhiều hàm dựng sẵn của MySQL. Nói chung, nhiều hàm có thể được chuyển đổi thành các UDF của DB2. Bạn quyết định sẽ chuyển đổi các hàm dựng sẵn nào thường được sử dụng. Đối với kịch bản ví dụ, cũng đáng bỏ công sức sử dụng các UDF của DB2 để chuyển đổi các hàm hoặc các thanh ghi của MySQL nếu bạn sử dụng chúng thường xuyên. Sau đây là một danh sách các hàm và các thanh ghi của MySQL mà bạn có thể chuyển đổi.  CURRENT_DATE() / CURDATE()  DATE_FORMAT()  DATEDIFF()  FROM_UNIXTIME()  NOW()  PERIOD_DIFF()  TO_DAYS()  UNIX_TIMESTAMP()  WEEKDAY()  YEARWEEK() Thật may, rất nhiều hàm nói trên đã được triển khai thực hiện và có sẵn miễn phí để sử dụng lại, như đã trình bày trong bài "Cơ sở về DB2: Trò vui với các ngày và giờ " (xem phần Tài nguyên). Nếu bạn đang sử dụng phiên bản v9.7.2 hoặc mới hơn của DB2, bạn có thể chọn thiết lập vector tương thích mới DB2_COMPATIBILITY_VECTOR=MYS. DB2 tạo dễ dàng các hàm do người dùng định nghĩa, do chúng có thể được viết bằng SQL thay vì yêu cầu sử dụng ngôn ngữ lập trình C, như trong trường hợp MySQL. Liệt kê 14 là một ví dụ về một UDF mà bạn có thể tạo ra để mô phỏng hàm NOW() của MySQL không chuẩn nhưng thường được sử dụng. Bạn có thể sử dụng mô phỏng này ở nhiều nơi trong ứng dụng ví dụ. Liệt kê 14. Định nghĩa một UDF của DB2 để mô phỏng hàm dựng sẵn NOW() của MySQL CREATE FUNCTION NOW() RETURNS TIMESTAMP NO EXTERNAL ACTION BEGIN ATOMIC RETURN SELECT CURRENT TIMESTAMP FROM SYSIBM.DUAL; END Có một số hàm khác do người dùng định nghĩa để mô phỏng các hàm dựng sẵn hay dùng của MySQL được liệt kê trong Phụ lục B của Sách Đỏ Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên). Di chuyển logic từ SQL sang PHP nếu cần
Có thể có các tình huống ở đó bạn không thể chuyển các hàm hoặc cú pháp của MySQL sang một định dạng thuận tiện của DB2. Trong trường hợp này, hãy xem xét liệu chính PHP có hỗ trợ tính năng ấy không và sử dụng hàm hoặc phần mở rộng đó để thay thế. Ví dụ, MySQL cung cấp một hàm SQL gọi là INET_ATON(), không có hàm tương đương trong DB2. Viết một hàm do người sử dụng định nghĩa thay cho INET_ATON() có thể tẻ nhạt và dễ mắc lỗi. May thay, PHP cung cấp hàm ip2long () có cùng chức năng và không phụ thuộc vào nhà cung cấp cơ sở dữ liệu. Về đầu trang Bước 2: Bắt đầu bước chuyển thứ hai trong di trú mã Với mã PHP được cập nhật để sửa đổi các câu lệnh SQL nhúng và để đọc hoặc cập nhật dữ liệu một cách tương tự như MySQL, bước tiếp theo là cấu trúc lại các truy vấn của bạn để đạt được các mục tiêu không có tính chức năng về toàn vẹn dữ liệu và cải thiện hiệu năng tốt hơn. Bước này liên quan đến các bước nhỏ sau đây:  Chọn cách tiếp cận thích hợp để xử lý đồng thời.  Hợp nhất các truy vấn để cải thiện chất lượng và hiệu năng dữ liệu. Chọn cách tiếp cận thích hợp để xử lý đồng thời Khi các truy vấn riêng lẻ được nhúng trong ứng dụng dựa vào MySQL đã được chuyển đổi để làm việc trên DB2 theo một mẫu tương đương, thì đây là lúc để xem xét cách có thể cải thiện chúng như thế nào để lợi dụng các tính năng xử lý đồng thời và toàn vẹn dữ liệu của DB2. Hãy xem xét các thay đổi cần thiết để hỗ trợ các mức cách ly thích hợp giữa một số kết nối đồng thời tới cơ sở dữ liệu. Có bốn mức cách ly trong DB2 để kiểm soát xử lý đồng thời. Các mức cách ly xác định cách một giao dịch ẩn giấu các thay đổi dữ liệu đang thực hiện khỏi những người dùng khác. Các mức cách ly như sau: Mức cách ly đọc lặp lại (RR) Tất cả các hàng bị khóa cho đến khi kết thúc giao dịch. Mức cách ly ổn định đọc (RS) Các hàng thỏa mãn điều kiện biến vị ngữ bị khóa cho đến khi kết thúc giao dịch. Mức cách ly ổn định con trỏ (CS) Chỉ có những hàng nào con trỏ đang trỏ vào bị khóa. Đây là mặc định. Mức cách ly đọc không cam kết (UR) Không có hàng nào bị khóa trừ khi dữ liệu đang thay đổi. Hãy xem xét mức cách ly nào phù hợp với ứng dụng của bạn từ một góc độ hiệu năng và tính toàn vẹn dữ liệu. Việc xử lý đồng thời giảm đi và tính toàn vẹn dữ liệu tăng lên khi bạn di chuyển mức cách ly từ đọc không cam kết (UR) sang đọc lặp lại (RR). Mức cách ly RR đảm bảo tính toàn vẹn dữ liệu tối đa phải trả bằng giá hiệu năng cao. Ngược lại, UR đảm bảo mức hiệu năng cao nhất phải trả bằng giá không nhất quán dữ liệu nào đó. Hình 1 minh họa các mối quan hệ giữa hiệu năng và tính toàn vẹn dữ liệu.
Hình 1. Các mức cách ly trong DB2 Bạn có thể quy định mức cách ly ở các mức khác nhau, từ các truy vấn riêng lẻ lên đến toàn bộ các kết nối và phiên làm việc đó. Nếu bạn có một tải công việc đọc rất nhiều, bạn có thể muốn thiết lập mức cách ly là đọc không cam kết (UR) ở mức kết nối để cho bạn không phải chỉ rõ nó trong mỗi câu lệnh. Nếu bạn có sự kết hợp các công việc đọc và viết, bạn có thể muốn tập trung vào chỉnh sửa các truy vấn riêng lẻ hơn là chỉ thay đổi khỏi mức cách ly mặc định là ổn định con trỏ (CS). Bạn có thể cũng muốn xem xét kiểu con trỏ mà bạn nên sử dụng để tối ưu hóa truy cập dữ liệu. Cả hai trình điều khiển ibm_db2 lẫn PDO_IBM đều hỗ trợ hai kiểu con trỏ: con trỏ chỉ tiến lên và con trỏ có thể cuộn được. Con trỏ mặc định là con trỏ chỉ tiến lên. Nói chung, con trỏ mặc định là một sự lựa chọn tốt cho phần lớn các trường hợp sử dụng, ở đó bạn lần lượt duyệt qua một tập kết quả. Xét về hiệu năng, con trỏ chỉ tiến lên tốt hơn so với con trỏ có thể cuộn được. Tuy nhiên, trong một số trường hợp, bạn sẽ cần phải đọc các con trỏ cả tiến lên và lùi lại, trong trường hợp này bạn nên sử dụng con trỏ cuộn. Trong kịch bản ví dụ, kiểu con trỏ được thiết lập bằng các lệnh trong Liệt kê 15 cho mỗi truy vấn cần thiết. Liệt kê 15. Định nghĩa kiểu cuộn của DB2 từ các hàm ibm_db2 và trình điều khiển PDO -- For ibm_db2 db2_exec($connection_resource, $sql, array('cursor' => DB2_SCROLLABLE)); -- For PDO_IBM $DB_PDO->prepare($sql, array(PDO::ATTR_CURSOR, PDO::CURSOR_SCROLL)); Xem mục 4.2 Sử dụng PHP với cơ sở dữ liệu DB2 trong Sách Đỏ Phát triển các ứng dụng PHP cho các máy chủ dữ liệu của IBM (xem phần Tài nguyên) để biết thêm chi tiết. Hợp nhất các truy vấn để cải thiện chất lượng và hiệu năng dữ liệu Tiếp theo, hãy nhóm các truy vấn thành các đơn vị lô-gic chứ không phải là các truy vấn độc lập. Trong bước chuyển di trú mã này, một khi bạn biết rằng các câu lệnh SQL đều đang nhận cùng một dữ liệu kết quả và các câu lệnh đều đang sửa đổi dữ liệu như chúng đã làm trong ứng dụng cũ, hãy xem xét việc nhóm lại các truy vấn truy cập và các cập nhật dữ liệu. Mục đích là để làm cho có mức hiệu năng của MySQL trong khi vẫn đảm bảo mức độ toàn vẹn dữ liệu của DB2.
Thu hẹp tỷ lệ các kết nối cơ sở dữ liệu so với các câu lệnh Nói chung, xây dựng một kết nối đến cơ sở dữ liệu trong MySQL thì nhanh hơn trong DB2. Do đó việc giảm số lượng tổng cộng các kết nối cho mỗi yêu cầu HTTP bằng cách sử dụng lại một kết nối cho nhiều hơn một truy vấn sẽ cải thiện hiệu năng của bộ xử lý, ổ đĩa và mạng. Với kịch bản ví dụ, các truy vấn được hợp nhất, bao gồm việc lấy thông tin tài khoản người dùng để thực hiện sẵn trước các phép nối nối rộng hơn (chứ không sử dụng một số các truy vấn tìm kiếm tiếp theo), như trong Liệt kê 16. Việc này có thể dẫn đến phải trả giá bằng việc tìm nạp trước quá nhiều dữ liệu, nhưng với kịch bản ví dụ này, hiệu năng được cải thiện, số lượng dữ liệu đã tìm nạp đã được giảm bớt và các nhà phát triển đã có một ý tưởng tốt hơn về thực sự cần lấy ra bao nhiêu dữ liệu cho một trang nhất định, do đó cũng tiết kiệm tài nguyên. Liệt kê 16. Hợp nhất các truy vấn -- Two individual queries that require two trips to the data server on the page SELECT FIN_PROJECT_MANAGER AS PM, PROJNAME FROM PROJECT WHERE ID = $id; SELECT EMAIL, FIRSTNAME, LASTNAME FROM USER WHERE ID = $pm; -- Single consolidated query that retrieves the same information in one trip SELECT U.EMAIL, U.FIRSTNAME, U.LASTNAME FROM USER U, PROJECT P WHERE U.ID = P.FIN_PROJECT_MANAGER AND PROJECT.ID = $id Tại sao không di trú Zend Framework? Cơ sở mã cho kịch bản ví dụ đã có trước hầu hết các khung công tác cho PHP. Các thành phần có thể sử dụng lại được từ PEAR và các thư viện mục đích đặc biệt như các tầng trừu tượng cơ sở dữ liệu đang bắt đầu có được sức lôi cuốn khi chúng tôi bắt đầu viết PTT vào năm 2002. Các khung công tác đủ trọn vẹn cả chồng công nghệ như CakePHP và Zend Framework chỉ xuất hiện nhiều năm về sau. Việc chấp nhận Zend Framework là một mục tiêu mong muốn trong tương lai, nhưng việc cập nhật mã ổn định để thay thế cơ sở dữ liệu và bắt đầu đặt các nền móng cho điều đó đã là phạm vi bao quát chính của việc di trú mã này. Cải tiến hướng đến một kiến trúc MVC dễ duy trì hơn Trong một ứng dụng web ba tầng có thiết kế tốt được xây dựng bằng cách sử dụng mẫu kiến trúc của mô hình-khung nhìn-trình điều khiển (MVC), trình điều khiển xử lý một yêu cầu web từ một người dùng và sau đó gọi một lệnh trên mô hình để chuẩn bị một kết quả. Đối tượng kết quả này được chuyển giao cho khung nhìn (thường biểu diễn bằng một khuôn mẫu HTML đơn giản) để hiển thị dữ liệu đáp ứng trên trang. Ứng dụng ban đầu đã không sử dụng mẫu MVC. Thay vào đó, ứng dụng đã nhúng các truy vấn trực tiếp vào các khuôn mẫu, hòa trộn thực sự cả ba nhiệm vụ vào một trang. Bằng việc chấp nhận một hướng dẫn thực hành tốt nhất về tạo nhóm các truy vấn của MVC, như lấy tất cả các thông tin tài khoản người dùng và tất cả các dự án cho người dùng đó trong một cuộc gọi duy nhất đến mô hình, trang khung nhìn chỉ cần hiển thị
thông tin, chứ không phải là từng bước tìm nạp thêm nhiều dữ liệu hơn. Cách tiếp cận này chuyển ứng dụng từ dữ liệu làm trung tâm hướng tới đối tượng nghiệp vụ làm trung tâm và do đó có thể giúp tổ chức mã của bạn tốt hơn bằng cách phân tách logic truy cập dữ liệu khỏi đánh dấu thiết kế và bố trí trang. Phân phối tốt hơn tải tính toán Bởi vì kịch bản ví dụ đã có một máy chủ web riêng và một máy chủ cơ sở dữ liệu riêng, nên máy chủ web chủ yếu là xử lý khối lưu lượng HTTP rất lớn. Máy chủ web đã thực hiện lô-gic phía máy chủ thông qua mô đun PHP. Để cải thiện hiệu năng ở máy chủ HTTP bằng cách giảm tiêu thụ CPU và bộ nhớ mà máy chủ web đã dùng trong mod_php, một số logic nghiệp vụ đã được chuyển cho máy chủ dữ liệu. Điều này đã thường mang lại thêm lợi ích, làm giảm tổng lưu lượng mạng (vì nó làm giảm lưu thông giữa máy chủ web và máy chủ dữ liệu) và do đó khả năng thông qua được tăng lên nhờ xử lý dữ liệu ở cùng một mức như nó đã được truy cập. Cải thiện tính toàn vẹn dữ liệu bằng cách nhóm các truy vấn trên máy chủ Lợi ích cuối cùng và quan trọng nhất cho sự toàn vẹn giao dịch là nhóm lô-gic xử lý thành các đơn vị giao dịch nguyên tử trên máy chủ dữ liệu khi sử dụng các thủ tục đã lưu, các tri-gơ và các hàm do người dùng định nghĩa. Bạn sẽ thấy rằng việc tạo các nhiệm vụ trong một ứng dụng như PTT đáng tin cậy hơn khi những điều sau đây xảy ra:  Tất cả các dữ liệu được chuyển giao toàn bộ tới cơ sở dữ liệu.  Nhiều câu lệnh INSERT được thực hiện cùng nhau như là một đơn vị.  Chỉ trả về cho người dùng một kết quả thành công hay một lỗi đã thất bại. Nếu không có một cơ sở dữ liệu đã hỗ trợ các giao dịch, thì một hoặc tất cả các sửa đổi cơ sở dữ liệu này có thể đã thất bại trong kịch bản ví dụ, do đó để lại hệ thống trong một trạng thái không thể dự đoán được, đòi hỏi có sự can thiệp của người dùng hoặc của nhà quản trị để giải quyết sự không nhất quán của dữ liệu, ví dụ như một nhiệm vụ chỉ được tạo một phần mà không có một chủ sở hữu hoặc liên kết quan trọng khác. Liệt kê 17 cho thấy một ví dụ về hai bản cập nhật có liên quan với nhau xảy ra như là một đơn vị nguyên tử. Liệt kê 17. Nhóm các bản nhật thành một thủ tục lưu sẵn CREATE PROCEDURE BILLING_TYPE_UPDATE (IN p_date DATE) BEGIN -- Update for project's billing type FOR row AS SELECT * FROM proj_billingtype_snapshot WHERE end_date IS NULL AND start_date = p_date DO -- Execute two updates in one transaction t1: begin atomic -- Transaction begins -- First update UPDATE fin_attributes
SET proj_type = row.billing_type WHERE project_id = row.proj_id; -- Second update UPDATE fin_attributes_archive SET proj_type = row.billing_type WHERE project_id = row.proj_id AND year = YEAR(NOW()); end t1; -- Transaction ends END FOR; END Tất cả các phiên bản của DB2 đều hỗ trợ các giao dịch, nhưng hầu hết các máy lưu trữ MySQL, bao gồm cả kiểu mặc định MyISAM, lại không hỗ trợ chúng. Ứng dụng ví dụ được xây dựng bằng cách sử dụng kiểu bảng MyISAM mặc định và các nhà phát triển đã cố gắng thực thi tính toàn vẹn dữ liệu ở mức mã. Cho nên việc di chuyển sang DB2 được chào đón vì đã có thể ủy thác quản lý giao dịch cho cơ sở dữ liệu, một việc mà DB2 làm rất tốt. Nó cũng làm giảm kích thước tổng thể và độ phức tạp của mã và các phần di chuyển khác nhau cần thiết để làm việc cùng nhau trên bất kỳ trang PHP cụ thể nào trong ứng dụng. Xem phần 5.2.8 Các giao dịch và mức cách ly trong Sách Đỏ Các ứng dụng của PHP cho các máy chủ dữ liệu của IBM (xem phần Tài nguyên) để tìm hiểu thêm về xử lý đồng thời trong DB2. Về đầu trang Bước 3: Bắt đầu kiểm tra trường hợp sử dụng nghiệp vụ lần đầu với các bên liên quan Vào lúc này, bạn phải có một hệ thống đang hoạt động có thể được kiểm tra toàn bộ hoặc ít nhất là một tập các chức năng có liên quan có một thành phần cụ thể. Ví dụ, việc tạo một nhiệm vụ mới được gắn với một dự án mẹ là một trường hợp sử dụng khá độc lập trong hệ thống PTT. Việc gửi một phần nội dung, ví dụ như một tiêu đề và mô tả sản phẩm, đến một dịch vụ dịch thuật là một trường hợp sử dụng khác có thể được kiểm tra độc lập. Bước chuyển đổi này bao gồm các bước nhỏ sau:  Biên dịch hoặc tạo các bài kiểm thử chấp nhận bởi người dùng.  Bài kiểm thử đơn vị và sửa lỗi.  Chụp một ảnh để sử dụng làm một vạch chuẩn. Biên dịch hoặc tạo các bài kiểm thử chấp nhận bởi người dùng Trong bước này, hãy bắt đầu đưa các bên liên quan quan tâm vào cuộc để thực thi một loạt các trường hợp sử dụng thường được thực hiện trong hệ thống cũ. Bạn muốn đảm bảo rằng cùng loạt các bài kiểm thử này làm việc như mong đợi trên hệ thống mới. Kịch bản ví dụ đã sử dụng một định dạng khá chuẩn cho việc kiểm tra chấp nhận của người dùng trong những năm qua. Vì vậy, có một kho lưu trữ các bài kiểm thử để xác nhận hợp lệ các tính năng mới và để tránh các vấn đề hồi quy với mã hiện có. Danh mục kiểm tra được mở rộng để
chứa các hàm trọng yếu đối với chức năng của PTT. Các bài kiểm thử này thường chứa một tập các bước có liên quan để đạt được một mục tiêu nghiệp vụ và chúng trông giống như một sơ đồ trường hợp sử dụng. Sự khác biệt so với một mô hình trường hợp sử dụng tĩnh là các bài kiểm thử thường được lưu trữ theo một định dạng bảng tính cùng với các ảnh chụp màn hình và các bảng có các hàng có thể cập nhật được, ở đó một người kiểm thử có thể nhập một loạt các bước cụ thể hay các bước riêng lẻ cho dù có thành công hoặc thất bại. Bảng 1 cho thấy một ví dụ về định dạng của trường hợp kiểm thử chấp nhận bởi người dùng để xác minh xem việc tạo nhiệm vụ đó đã làm việc như đã mong đợi chưa. Bảng 1. Bài kiểm thử chấp nhận bởi người dùng mẫu Test Expected result Passed? 1.1 Đăng nhập vào hệ Trang chào đón được hiển thị. Có thống. 1. Tạo một 1.2 Mở trang nhiệm vụ Tải biểu mẫu nhiệm vụ mới. Có nhiệm vụ mới mới. 1.3 Điền vào biểu mẫu Hiển thị thông báo thành công và liên kết Có và lưu trữ. của ID duy nhất của nhiệm vụ. 2.1 Log into the Trang chào đón được hiển thị. Có system. 2. Phê duyệt 2.2 Đăng nhập vào hệ Danh sách các tải công việc. Có nhiệm vụ thống. 2.3 Định vị danh sách Hiển thị thông báo thành công và gửi email. Không các nhiệm vụ. Hãy ghi nhớ rằng điều cực kỳ quan trọng là những người kiểm thử của bạn dành đủ thời gian để thực hiện các bài kiểm thử chấp nhận bởi người dùng và ghi lại bất kỳ vấn đề nào. Nếu họ chỉ đọc lướt các bài kiểm thử, họ có thể bỏ sót các lỗi. Cũng với lý do tương tự, điều quan trọng là lập sổ ghi ai đã kiểm thử vào lúc nào và các kết quả họ đã báo cáo là gì để thực thi trách nhiệm giải trình. Bài kiểm thử đơn vị và sửa lỗi Bước này đòi hỏi phân tích có hệ thống các vấn đề do những người kiểm thử chấp nhận bởi người dùng báo cáo. Khi nhận được các bài kiểm thử chấp nhận bởi người dùng từ những người kiểm thử, cần giao cho cá nhân các nhà phát triển những vấn đề đã được báo cáo để xác nhận và sửa chữa. Ví dụ, bài kiểm thử 2.3 trong Bảng 1 sẽ được quy như là một lỗi mới. Khi bạn di trú hệ thống theo cách lặp nhiều lần, các nhà phát triển cần so sánh chức năng đã di trú vào DB2 với hệ thống nguồn MySQL ban đầu để đảm bảo rằng các đơn vị công việc cụ thể được thực hiện như mong đợi. Với các bài kiểm thử chấp nhận bởi người dùng, sẽ rất có giá trị nếu tự động hóa quá trình này bằng cách sử dụng một khung công tác kiểm thử đơn vị, ví dụ như PHPUnit. Vì cơ sở mã ví dụ không được phân chia đúng thành mã MVC, thích hợp với dễ kiểm thử theo chương trình, nên bài kiểm thử đơn vị tự động hóa hoặc hệ thống tích hợp liên tục không được sử dụng.
Chụp một ảnh để dùng làm vạch chuẩn Sau khi phần chính của các trường hợp sử dụng đã hoàn thành, bước cuối cùng trước khi bắt đầu một vòng lặp kiểm thử mới là chụp ảnh hiện trạng hệ thống làm một bản sao lưu và một vạch chuẩn để tham chiếu lại khi kiểm tra xác nhận hoạt động và hiệu năng. Một lần nữa, mỗi khi các vòng lặp thay đổi đạt đến một mốc ổn định, điều quan trọng là chụp ảnh các bản sao lưu. Ảnh này có thể là dạng tệp truyền thống và các bản sao lưu SQL hoặc có thể là dạng các ảnh hoàn chỉnh của hệ điều hành. Điều rất quan trọng nữa là duy trì các điểm lưu trữ này trong trường hợp có một lỗi trong tương lai hoặc để sử dụng làm một vạch chuẩn so sánh. Về đầu trang Bước 4: Giải quyết nút nghẽn cổ chai và xác nhận dựa vào vạch chuẩn chức năng Một khi tập hoàn chỉnh các bài kiểm thử chấp nhận bởi người dùng đã được các bên liên quan của bạn ký duyệt, đây là lúc để cải thiện hiệu năng của hệ thống. Bước này đòi hỏi hoàn thành các bước sau đây:  Xác nhận các bài kiểm thử chấp nhận bởi người dùng (UAT) là vạch chuẩn.  Sử dụng các công cụ để sửa chữa các vấn đề hiệu năng trong DB2.  Xác định vị trí và giải quyết các nút nghẽn cổ chai trong hệ điều hành. Xác nhận các bài kiểm thử UAT vạch chuẩn Với bước chuẩn bị này, điều quan trọng cần nhắc lại là bạn cần có một khung nhìn rõ ràng về chức năng hệ thống đã xác nhận sao cho bạn biết liệu có bất kỳ yêu cầu cải tiến phi chức năng nào không, ví dụ như các cải tiến hiệu năng, có ảnh hưởng tốt hoặc phải đánh đổi bằng các yêu cầu chức năng đã thống nhất. Bước này nên diễn ra sau khi kiểm tra xác nhận chức năng vì hai lý do. Đầu tiên, nó đảm bảo rằng bạn có một vạch chuẩn chức năng đã được ký duyệt, đã được biết rõ trước khi thực hiện bất kỳ các thay đổi phi chức năng nào. Thứ hai, nó giúp bạn tránh các cạm bẫy của việc tối ưu hóa vội vàng trong việc di trú của bạn. Bạn có thể biết rằng một truy vấn hoặc cách tiếp cận nào đó nhanh hơn trong một trường hợp, nhưng bạn không nên áp dụng một cách mù quáng một sự thay đổi trên toàn bộ cơ sở mã, đặc biệt là khi không có dấu hiệu nào cho thấy có một vấn đề hiệu năng. Lấy ví dụ, một lịch sử các bài kiểm thử chấp nhận bởi người dùng đã được lưu giữ để xác nhận liệu có gì đó đã được kiểm thử và thành công trước đó chưa để dùng kiểm tra các vấn đề hồi quy nếu chúng xuất hiện sau này. Sử dụng các công cụ để sửa chữa các vấn đề hiệu năng trong DB2 Những mối hiểm họa của việc tối ưu hóa vội vàng Có khả năng bạn đã nghe nói về nhận xét của Donald Knuth vào năm 1974 rằng "việc tối ưu hóa vội vàng là gốc rễ của mọi tội lỗi". Một ví dụ về các cạm bẫy của vấn đề này xuất phát từ kinh nghiệm của một trong những tác giả của loạt bài này (chúng tôi không nêu rõ tên người phạm
lỗi!). Khi ông đã biết rằng các chuỗi ký tự dùng dấu nháy đơn thực hiện tốt hơn so với các chuỗi ký tự dùng dấu nháy kép (do thực tế là các biến nội suy không bị thay thế khi được bọc trong các dấu nháy đơn), ông đã quyết định có lẽ thật tốt để thay thế tất cả các dấu nháy kép bằng các dấu nháy đơn. Ông đã không có lý do nào để nghĩ rằng ứng dụng này đã đang có các vấn đề hiệu năng, nên ông đã thực hiện những gì ông nghĩ là tìm kiếm và thay thế cẩn thận hơn. Thật không may, ông đã bỏ sót một hoặc hai chuỗi nội suy và đưa vào một lỗi rất khó phát hiện, đã gây ra các vấn đề toàn vẹn dữ liệu trong tương lai. Tuy nhiên, chúng tôi đã tha lỗi cho ông. Việc kiểm thử của bạn vào thời điểm này nên tập trung chủ yếu vào những gì DB2 có thể sửa chữa tự động cho bạn, vì DB2 là sự thay đổi lớn nhất mà bạn đưa vào. Khi bạn thay đổi mã, bài kiểm thử đơn vị và thực hiện kiểm thử chấp nhận bởi người dùng (UAT), bạn nên xác định các nút nghẽn cổ chai và thực hiện các thay đổi khi cần. Một triết lý quan trọng cần làm theo là chỉ thay đổi những điều đã biết là có vấn đề thông qua bài kiểm thử đơn vị và việc kiểm tra UAT còn hơn là thực hiện các giả định về các nguồn tiềm năng của các vấn đề hiệu năng. Sau khi thực hiện điều này, bạn có thể cung cấp những gì đã được thay đổi và ghi lại nó để các ứng dụng tương lai chống lại các lỗi sau này. Có một sự cân bằng mong manh giữa việc tối ưu hóa vội vàng và áp dụng các bản sửa lỗi trên diện rộng dựa vào một danh sách các hướng dẫn thực hành tốt nhất. Đây sẽ là một quá trình lặp lại trong suốt vòng đời của ứng dụng. Xem phần bên về các mối hiểm họa của việc tối ưu hóa vội vàng. Một kỹ thuật mà bạn có thể thấy có ích là thực hiện một hàm, giám sát các kịch bản lệnh chạy quá 60 giây và gửi một báo cáo lỗi, như đã được thực hiện cho ứng dụng ví dụ PTT. Một ví dụ của hàm này được mô tả trong phần 4 của loạt bài này. Dựa vào thông tin có sẵn trong báo cáo đó, bạn có thể phát hiện ra là liệu có vấn đề phát sinh ra từ một kết quả của việc thực hiện PHP chậm hay một truy vấn chậm không. Với các vấn đề về PHP, một trình gỡ lỗi như trình gỡ lỗi có sẵn trong Zend Studio hoặc Eclipse PDT có thể giúp bạn định vị các vấn đề. Với các vấn đề truy vấn, bạn có thể sử dụng IBM Data Studio để định vị các vấn đề và đề xuất sửa chữa. Hình 2 cho thấy một ví dụ của biểu đồ kế hoạch truy cập cho một truy vấn cụ thể.