Cái "khổ" của việc quản lý dữ liệu lịch sử
Là người làm lập trình, chắc hẳn ai cũng từng gặp tình huống này: Bạn xây dựng một hệ thống quản lý nhân sự hay tài sản rất mượt mà. Mọi thứ đều ổn cho đến khi sếp hoặc khách hàng nói: "Tôi không chỉ muốn biết hiện tại họ đang ở đâu; tôi muốn xem lại toàn bộ quá trình họ đã làm gì trong 10 năm qua."
Ngay lập tức, logic "Update" (Cập nhật) đơn giản của bạn biến thành một cơn ác mộng:
Mẹo "Hash-Stack": Sự tinh tế trong đơn giản
Nhiều năm trước, tôi đã ngừng việc xây dựng các bảng lịch sử riêng biệt. Thay vào đó, tôi sử dụng một quy ước đặt tên đơn giản, biến một bảng phẳng (flat table) thành một "ngăn xếp" (stack) lịch sử có tốc độ truy xuất cực nhanh.
Cách làm như sau:
Khi một trạng thái thay đổi (ví dụ: thuyền viên rời tàu), đừng di chuyển dữ liệu đi đâu cả. Chỉ cần đổi tên Mã định danh (Primary Key) của họ:
Mã_Gốc $\rightarrow$ Mã_Gốc + "#" + Ngày_Cất_Kho (YYYYMMDD)
Tại sao cách này lại "ăn đứt" mọi giải pháp khác?
Dấu sao (*) sẽ ngay lập tức gọi ra mọi "mẩu giấy" lịch sử về người đó theo đúng thứ tự thời gian.
Chúng ta thường quá phức tạp hóa vấn đề bằng những cấu trúc quan hệ rắc rối. Nhưng đôi khi, giải pháp "đẳng cấp" nhất lại chỉ là một mẹo xử lý chuỗi ký tự thông minh và một dấu đại diện (wildcard).
Đừng ghi đè lên hiện tại. Hãy xếp chồng quá khứ lên nhau. Bản thân bạn (và những người kiểm toán sau này) sẽ phải thầm cảm ơn vì quyết định đó.
Là người làm lập trình, chắc hẳn ai cũng từng gặp tình huống này: Bạn xây dựng một hệ thống quản lý nhân sự hay tài sản rất mượt mà. Mọi thứ đều ổn cho đến khi sếp hoặc khách hàng nói: "Tôi không chỉ muốn biết hiện tại họ đang ở đâu; tôi muốn xem lại toàn bộ quá trình họ đã làm gì trong 10 năm qua."
Ngay lập tức, logic "Update" (Cập nhật) đơn giản của bạn biến thành một cơn ác mộng:
- Xáo trộn bảng biểu (Table Shuffle): Bạn phải tạo thêm một bảng "Hiện tại" và một bảng "Lịch sử".
- Gánh nặng mã nguồn: Mỗi khi dữ liệu thay đổi, bạn phải viết những đoạn code phức tạp để:
- Tìm bản ghi cũ.
- Sao chép nó.
- Dán vào bảng Lịch sử.
- Sau đó mới được cập nhật bản ghi mới vào bảng Hiện tại.
- Nỗi đau truy xuất: Khi cần một báo cáo đầy đủ, bạn bị kẹt trong những câu lệnh JOIN hoặc UNION nặng nề, khiến hệ thống chạy chậm như rùa khi dữ liệu phình to.
Mẹo "Hash-Stack": Sự tinh tế trong đơn giản
Nhiều năm trước, tôi đã ngừng việc xây dựng các bảng lịch sử riêng biệt. Thay vào đó, tôi sử dụng một quy ước đặt tên đơn giản, biến một bảng phẳng (flat table) thành một "ngăn xếp" (stack) lịch sử có tốc độ truy xuất cực nhanh.
Cách làm như sau:
Khi một trạng thái thay đổi (ví dụ: thuyền viên rời tàu), đừng di chuyển dữ liệu đi đâu cả. Chỉ cần đổi tên Mã định danh (Primary Key) của họ:
Mã_Gốc $\rightarrow$ Mã_Gốc + "#" + Ngày_Cất_Kho (YYYYMMDD)
Tại sao cách này lại "ăn đứt" mọi giải pháp khác?
- Lịch sử trong nháy mắt: Bạn muốn xem toàn bộ lịch sử của nhân viên TV_101? Không cần những câu lệnh truy vấn phức tạp. Chỉ cần lọc (filter) cột Mã với điều kiện:
Dấu sao (*) sẽ ngay lập tức gọi ra mọi "mẩu giấy" lịch sử về người đó theo đúng thứ tự thời gian.
- Không cần di chuyển dữ liệu: Không còn việc sao chép dòng từ bảng này sang bảng kia. Không còn nỗi lo về hàm "Push/Pop" (đẩy vào/lấy ra). Mọi thứ nằm yên một chỗ, bất biến và vẹn nguyên.
- Giao diện luôn sạch sẽ: Các màn hình làm việc hiện hành của bạn chỉ cần tìm các mã "sạch" (không có dấu #). Toàn bộ "bóng ma" của quá khứ (các bản ghi có dấu #) sẽ ẩn mình ở phía sau cho đến khi bạn cần gọi chúng lên.
Chúng ta thường quá phức tạp hóa vấn đề bằng những cấu trúc quan hệ rắc rối. Nhưng đôi khi, giải pháp "đẳng cấp" nhất lại chỉ là một mẹo xử lý chuỗi ký tự thông minh và một dấu đại diện (wildcard).
Đừng ghi đè lên hiện tại. Hãy xếp chồng quá khứ lên nhau. Bản thân bạn (và những người kiểm toán sau này) sẽ phải thầm cảm ơn vì quyết định đó.
