Chúng ta cần biết gì ở 1 database ?

Đối với một lập trình viên, hiểu biết về Database là 1 phần cực kỳ quan trọng không thể thiếu. Tuy nhiên có thể do điều kiện việc làm và kiến thức còn hạn chế, rất nhiều Developer có hiểu biết còn hời hợt về Database. Tại sao lại như vậy ?

Nguyên nhân của việc này là do khi đi làm việc đặc biệt là theo nhóm hoặc theo 1 dự án, thường các bạn sẽ không được thiết kế DB mà là dựa theo DB có sẵn để viết truy vấn. Các tiền bối phía trước phần vì thiếu thời gian để viết các tài liệu cần thiết, phần vì các bạn cũng thường có mong muốn làm được việc ngay, nên hay bỏ qua những yếu tố quan trọng trên DB. Về lâu về dài sẽ quên đi mất.Vậy hôm nay chúng ta cùng điểm qua một vài thứ mà có thể các bạn đã quên:

1. Phân quyền database: Một trong những thứ khá quan trọng, nhưng thường bị đánh giá thấp là việc phân quyền DB trong dự án. Thông thường một dự án sẽ có vài DB cho các môi trường dev/test/staging/production. Và mỗi môi trường, với mỗi thành viên lại cần 1 account khác nhau. Việc này giúp giảm thiểu các rủi ro liên quan tới các dữ liệu quan trọng, tránh “xóa nhầm” hay “tương tác nhầm DB” rất hay gặp.
2. Trùng lặp dữ liệu:
   Trrong thiết kế DB chuẩn, có 1 yêu cầu mà chúng ta rất hay “bỏ qua” vì nó bất tiện cho việc truy vấn, đó là trùng lặp dữ liệu.
   Giả sử: Chúng ta có các bảng sau:
   School(id, name, address, … )
   Class(id, name, year, school_id, …)
   Student(id, name, dob, school_id, class_id, …)
   
   Tại bảng Student, chúng ta thấy có school_id và class_id, và trong class_id thì lại có school_id. Theo nguyên tắc tránh trùng lặp, việc đưa school_id vào bảng Student là không cần thiết, vì từ class_id có thể truy ra school_id rồi. Nhưng vì lý do nào đó, khi thiết kế DB, chúng ta muốn truy xuất rõ ràng, nên thêm vào để dễ truy xuất.
   Việc này nếu có thể thì nên tránh. Vì nó sẽ làm cho Database bị chồng dữ liệu và phát sinh khả năng các dữ liệu không ăn khớp với nhau, dẫn tới lỗi.
3. Không hoặc thiếu khai báo CONSTRAINT:
   Constraint là ràng buộc dữ liệu trong DB, giúp cho DB của bạn không có các trường hợp “lạ”. Đã ai trong số Dev chưa từng gặp tình trạng bị tester thêm những Data “lạ” vào DB chưa ? Ai mà chưa từng trải thì chắc là chiếu mới rồi :)).
   Và việc này thì đúng là để giúp cho data của các bạn luôn vẹn toàn và không bị những lỗi lạ thế này. PRIMARY KEY, UNIQUE, NOT NULL, DEFAULT, FOREIGN KEY, là những CONSTRAINT phổ biến. Tuy nhiên các bạn có biết rằng còn 1 số CONSTRAINT nữa hay được sử dụng, là CHECK, dùng để check 1 điều kiện bất kỳ. Ví dụ status chỉ được nằm trong khoảng giá trị này, type chỉ được chứa giá gị này …
4. Khai báo thông tin bảng trong Database:
   Khi khởi tạo Database hoặc bảng, chúng ta thường bỏ quên các giá trị mà thường được set mặc định. Đó là Collate, đó là Engine. Phần COLLATE sẽ ảnh hưởng tới format và giá trị lưu trữ trong DB, khai báo COLLATE không hợp lý sẽ dẫn tới lượng storage cần thiết không hiệu quả. Giả sử bạn cần lưu trữ giá trị chuỗi chỉ chứa ký từ a-z, thì UTF8 có phải lựa chọn tối ưu ? Hay với database của Blog/News cơ chế đơn giản không có Foreign Key, thì các bạn có nên sử dụng Engine InnoDB với cơ chế phục hồi lỗi cao, nhưng sử dụng nhiều RAM/CPU hơn không ?
   Những thứ này thông thường cần được quyết định trước khi DB được tạo ra. Nhưng như đã nói, với Junior/Fresher thì làm gì có mấy cơ hội được tạo DB ?
5. Đặt index và limit data khi truy xuất:
   Ok, đặt Index và limit data khi truy xuất thường bị bỏ quên đối với những câu querry được viết “đời đầu” vì lúc chưa có nhiều dữ liệu, tốc độ truy xuất vẫn ổn. Tuy nhiên về lâu về dài, chẳng hạn MySQL, khi truy xuất 1 lượng dữ liệu tầm >10000 record là tốc dộ bắt đầu giảm đi đáng kể.
   Vậy nên vì lý do này, khi viết query, chúng ta nên dự tính các trường hợp từ khi bắt đầu viết Query.

Ok, hôm nay tới đây thôi.

Tác giả: Cao Văn Thành