Trong thực tế có nhiều tình huống các ứng dụng cần đồng bộ dữ liệu giữa các table với nhau điển hình như:
Ứng dụng với CSDL phân tán.
Ứng dụng Data Warehouse cần nhận biết dữ liệu update, insert để làm mới dữ liệu.
…
Cách truyền thống để so sánh sự thay đổi dữ liệu từ bảng nguồn so với bảng đích là so sánh giá trị trên từng field của từng dòng trong table, kỹ thuật này rất thủ công và cũng rất chậm và tốn nhiều thời gian cũng như tài nguyên hệ thống.
Cách thứ hai bài bản hơn là dùng Change Tracking để nhận diện các dòng đã được thay đổi ở bảng nguồn, dựa vào đó để update dữ liệu tới bảng đích. Tuy nhiên kỹ thuật này đòi hỏi phải tạo thêm table (do SQL Server tự động tạo ra vào database của ứng dụng, nhìn rối rắm và có thể làm tăng kích thước của database không cần thiết), cách dùng kỹ thuật này mặc dù dễ nhưng cũng không đơn giản lắm.
Cách thứ ba là dùng Change Data Capture, nhưng kỹ thuật này lại khó dùng hơn giải pháp thứ 2 ở trên và lại phụ thuộc vào phiên bản của SQL Server, không có trong SQL Express.
Tuy nhiên, may mắn là chúng ta có một kỹ thuật đơn giản và nhanh hơn nhiều, rất phù hợp để ứng dụng trong thực tế. Đó là dùng hàm HASHBYTES () có từ phiên bản SQL 2005.
Để đồng bộ dữ liệu từ table nguồn A tới table đích B, ở trên cả hai table ta tạo ra một column để lưu giá trị HASHBYTES của nguyên dòng dữ liệu đó.
Giá trị này đóng vai trò như dấu vân tay (fingerprint) của từng dòng dữ liệu trong bảng, giá trị này sẽ được tạo mới sau mỗi lần thêm dòng, hoặc update giá trị mới vào một cột nào đó bằng cách sử dụng trigger.
Khi cần lấy những dòng dữ liệu đã được thay đổi ở bảng nguồn, chỉ cần join hai table A và B căn cứ trên Primary Key và so sánh giá trị ở cột Hashbytes này, nếu giá trị này khác nhau ở hai dòng có primary key bằng nhau của hai bảng A và B thì có nghĩa là đã có sự thay đổi ở bảng nguồn, cần phải update bảng đích.
Chính vì chỉ update những dữ liệu đã được thay đổi và chỉ cần so sánh giá trị của duy nhất một field trong bảng nên kỹ thuật này đạt yêu cầu về tốc độ và sự đơn giản cho việc triển khai trong thực tế.
Bước 1: Tạo ra hai table sourceTable và destTable có cấu trúc như nhau
Bước 2: Tạo trigger trên bảng nguồn để tạo giá trị hashbytes mỗi lần có sự thay đổi trên bảng
— tao trigger de update gia tri HastByte
CREATE TRIGGER trgUpdateHashValue ON sourceTable
Bước 3: Insert một số dòng vào cả hai table và xem giá trị hashbytes được tự động tạo ra:
— Insert gia tri vao hai bang
— insert cac dong nay vao table dich
Bước 4: Giả sử bây giờ có sự thay đổi ở sourceTable, người dùng update dòng thứ nhất, cột Name từ TPHCM thành Vung Tau. Chúng ta sẽ đồng bộ sự thay đổi này từ sourceTable vào destTable
Như chúng ta thấy ở trên, sự thay đổi đã được đồng bộ thông qua câu lệnh update đơn giản.
Với các dòng mới thêm vào ở sourceTable, chúng ta đồng bộ nó vào destTable bằng câu lệnh:
Trong thực tế với tính năng Reptication của SQL Server có nhiều hạn chế và không mềm dẻo lắm. Trong khi thực tế đặt ra nhiều tình huống rất phức tạp, thậm chí chẳng theo một logic cụ thể rõ ràng nào cả, trong trường hợp đó Replication khó lòng xử lý được, ngoài ra cũng có hạn chế với phiên bản SQL Express.
Đối với việc động bộ dự liệu thường xảy ra trong các trường hợp sau: Vậy để có giải pháp cụ thể cho từng trường hợp, trước hết phải xác định rõ là đang ở trường hợp nào.
TH1: Đồng bộ dữ liệu một chiều từ DB1 sang DB2 hoặc ngược lại (DB2 là database tổng hợp, giống như máy chủ đặt tại Sài gòn, máy con đặt tại Vũng tàu, định kỳ đồng bộ dữ liệu từ máy con ở Vũng Tàu về SG).
TH3: Đồng bộ dữ liệu 2 chiều, gộp kết quả từ DB1 sang DB2 và ngược lại, có nghĩa cả hai DB1 và DB2 đều có dữ liệu ở tất cả các bảng y chang nhau, cái này là bản sao của cái kia.
Tiếp theo, phải xem xét cách thiết kế database như thế nào, cụ thể Primary Key các table được thiết kế như thế nào:
Nếu dùng cột Identity để tạo khóa chính, có khó khăn là dữ liệu ở hai table giống nhau trong hai database DB1 và DB2 có thể bị trùng khóa mà bản thân hai dòng dữ liệu ở hai table là hoàn toàn khác nhau, ở DB1 có ID = 1 thì dòng bán hàng là của vũng tàu, ở DB2 cũng có ID là 1 nhưng dòng bán hàng lại là của TPHCM. Như vậy nếu chỉ có cột ID làm khóa thì rất khó để đồng bộ dữ liệu được chính xác.
Từ phân tích trên, chúng ta phải cấu trúc lại table trong hai database để có thể đồng bộ dữ liệu.
Thêm một cột ví dụ như DBID để xác định dòng dữ liệu thuộc database nào để nó kết hợp với cột ID tạo thành một Unique Key.
Tạo một cột duy nhất làm khóa, nhưng giá trị của cột này là sự kết hợp giá trị của cột ID và cột DBID ở trên, ví dụ giá trị của cột Key này ở DB1 là: DB1_1, DB1_2, DB1_3…, DB2 là: DB2_1, DB2_2, DB3_3.
Cũng có thể tạo ra cột có kiểu là uniqueidentifier, nhưng với dữ liệu nhỏ thì có thể được, nhưng dữ liệu lớn thì không nên, vì cột có kiểu này chiếm không gian rất lớn và có thể ảnh hưởng đến perfomance.
Sưu tầm Internet (http://www.bigdata.com.vn)