Mười lỗi lớn nhất các nhà phát triển hay mắc phải với CSDL

Bạn có thể mới update một giao diện Web AJAX tuyệt vời, hay giao diện người dùng Windows “hàng khủng” mới nhất, nhưng dù làm gì đi chăng nữa, bạn cũng không thể bỏ qua cơ sở dữ liệu. Dù phần mềm phát triển đến đâu, hiện đại ra sao, đẹp đẽ thế nào thì việc đưa dữ liệu vào ra vẫn cần được thực hiện thường xuyên với những thao tác đã từng xuất hiện từ hàng thập kỷ trước. Và, thật đáng ngạc nhiên là các nhà phát triển phần mềm vẫn mắc phải những lỗi cơ bản về cơ sở dữ liệu như thời kỳ của Windows 95. Có lẽ, hầu hết chúng ta chỉ mới học cách sử dụng cơ sở dữ liệu chứ chưa thực sự nghiên cứu về nó. Dưới đây là một số lỗi được cho là lớn nhất và thường gặp nhất khi làm việc với cơ sở dữ liệu (CSDL).

Chọn sai CSDL

Không phải tất cả CSDL đều được tạo ra như nhau. Có nghĩa là trước khi thực hiện việc gì, hãy chắc chắn rằng bạn đã chọn đúng CSDL phù hợp. Đã từng có nhiều trường hợp, CSDL Access “trĩu xuống” vì phải tải những tập hợp dữ liệu khổng lồ, trong khi chúng chỉ là trò chơi trẻ con với SQL Sever. Một số người dùng phiền phức còn cố gắng trả tiền và cài đặt SQL Sever cho CSDL chỉ với vài trăm hàng. Xét trên diện rộng, thị trường hiện nay có 3 tầng CSDL: tầng thứ nhất dành cho máy tính cá nhân (tầng desktop) với CSDL nhúng, phù hợp cho các công việc nhỏ; tầng thứ hai là phiên bản “Express” của những người chơi lớn, với dung lượng khoảng vài Gigabyte dữ liệu; tầng thứ ba là lớp CSDL doanh nghiệp như SQL Sever, Oracle và DB2, có thể kiểm soát tất cả những gì bạn đưa vào. Trước khi bắt tay vào làm việc, bạn cần đánh giá ước lượng thực tế tổng lượng dữ liệu sẽ lưu trữ trong tương lai để chọn loại sản phẩm cho phù hợp.

Chọn quá nhiều CSDL

Các API như ODBC, JDBC và OLE DB bây giờ có xu hướng thúc đẩy mạnh khái niệm độc lập của CSDL. Tức là bạn có thể viết mã nguồn chương trình ứng dụng và đưa bất kỳ CSDL nào vào khu vực lưu trữ dữ liệu cũng được. Đã từng có nhiều đội phát triển đi vào bế tắc với độc lập CSDL, viết các tầng dịch tất cả lệnh SQL Sever sang một số dạng tiếng địa phương mẫu thức chung thấp nhất mà mọi CSDL nhận thức được hỗ trợ. Như thế cũng có nghĩa là từ bỏ một số chức năng nâng cao ở CSDL. Khái niệm này dường như nói rằng, một số client trong tương lai có thể sẽ chuyển sang Oracle hoặc DB2 hoặc FoxPro... Vì thế, tốt hơn hết là nên chuẩn bị từ bây giờ. Ngược lại, khi bắt đầu với một sản phẩm mới, hãy chọn cơ chế lưu trữ và viết CSDL phù hợp. Nếu sản phẩm của bạn tốt, mọi người sẽ cài đặt CSDL bạn mô tả. Lúc đó, bạn sẽ không bị lãng phí hàng giờ cho công việc hỗ trợ những thứ không bao giờ cần dùng đến.

Bạn đã hiểu dữ liệu của mình?

Nếu có thể thu được một 1 đô la sau mỗi lần trả cho khách hàng tài khoản 6 con số thay vì 7 như thực tế, hay nếu văn phòng quản lý hồ sơ thực sự cho phép sinh viên học sinh đăng ký mà không cần dùng đến số chứng minh thư nhân dân và cột ID trong CSDL phải cho phép NULL, thì đảm bảo rất nhiều quản trị viên DBA đã giàu không kể xiết. Thiết kế CSDL không thể thực hiện bừa bãi, bỏ qua mọi luật lệ, quy định thương mại. Bạn cần phải hiểu dữ liệu đầu vào của người dùng thực thuộc kiểu gì; có thể nén nó lại đến bao nhiêu để có được độ lớn cột cho phù hợp; các nguyên tắc áp dụng cho nó là gì; kiểu dữ liệu nào cho từng cột; ai có quyền update, v.v….

Không phải lúc nào cũng đơn giản như Excel

Hiện nay có một xu hướng, nhất là trong quan niệm của các quản lý cửa hàng nhỏ cho rằng, bất kỳ nhà phát triển nào cũng biết cách cài đặt một CSDL. Thành thật mà nói, chưa hẳn đã đúng. Liệu có phải tất cả các nhà phát triển đều biết cách viết mã nguồn trên C# hay cài đặt dịch vụ web (Web Service). Nếu thế thì tất cả chúng ta đều có thể là chuyên gia CSDL. Có quá nhiều CSDL được thiết kế bởi những người thậm chí chưa từng nghe nói đến các thuật ngữ cơ bản, cũng không buồn bận tâm nâng cao kiến thức, hiểu biết về các dạng thông thường khác nhau của CSDL. Không biết bao nhiêu lần tôi được chứng kiến tất cả dữ liệu bị dồn vào một bảng lớn., dẫn đến nhiều vấn đề bất thường xuất hiện khi update và thực thi dữ liệu. Nếu bạn đang gặp phải vấn đề này, hãy học thêm về thiết kế CSDL. Đừng khám phá mọi thứ về chỉ qua các bản thử nghiệm và lỗi gặp phải.

Kiểu bình thường của nhóm thứ ba không phải là “chén Thánh”

Nói cách khác, đôi khi một chút kiến thức nhỏ cũng có thể trở thành thứ nguy hiểm. Tôi đã từng chứng kiến một số CSDL được bình tường hoá tới mức kẹt cứng bởi các nhà phát triển “thiện chí”, những người một mực khăng khăng đặt tất cả mọi thứ vào các bảng tra tìm. Và một phiên hoạt động đáng ghi nhớ, trong đó “yes” và “no” được bỏ vào tblAnswers. Bảng này có thể tham chiếu bởi khoá ngoại AnswerID từ các bảng khác. Phải, bạn cần biết các nguyên tắc bình thường hoá, nhưng cũng cần phát triển kỹ năng để hiểu khi nào thì nên ngừng, khi nào nên loại bỏ hoạt động này cho các thực thi thực sự.

Thật tuyệt vời với các ứng dụng logic ẩn!

Các thủ tục và ràng buộc lưu trữ là những thành phần tuyệt vời. Khi có nhiều client truy cập CSDL cùng một lúc, các thủ tục, ràng buộc này giúp đảm bảo tính nhất quán của dữ liệu. Đồng thời chúng cũng có thể quay trở lại một hộp đen chứa các ứng dụng logic ẩn, thông thường không được nhìn thấy và không thể xem. Có rất nhiều mã CSDL không có cùng tiêu chuẩn thiết kế, kiểm tra, xem lại mã nguồn giống nhau như yêu cầu. Khi có ý định đặt mã nguồn vào CSDL, bạn hãy dành ra chút thời gian tự hỏi lại xem nó có thực sự thuộc về nơi đó không.

Ai cần những bản sao lưu?

Ai cần những bản sao lưu? Chính là các bạn, những người quản trị CSDL hay các nhà phát triển. Vì đơn giản, công việc của các bạn chắc chắn phải lưu trữ dữ liệu trong một Database (CSDL). Có thể, vào một lúc nào đó, vì một lý do nào đó như lỗi phần cứng, hacker tấn công, hay đơn giản chỉ bởi các lỗi thông thường mà CSDL của bạn gặp trục trặc, bị mất mát hoặc phải cài đặt lại. Khi ấy, chắc chắn bạn sẽ cần đến những bản sao lưu. Kế hoạch sao lưu (như tần suất thực hiện, kiểu sao lưu…) cần được thực hiện vào thời điểm từ khi bắt đầu chu trình phát triển chứ không phải đợi đến khi hoàn thành mới tiến hành.

Bạn cần kiểm soát phiên bản

Nói đến sao lưu, bên cạnh các thay đổi về dữ liệu, bạn cũng cần theo dõi thay đổi về giản đồ CSDL, chủ động tinh thần sẵn sàng tạo lại CSDL vào bất cứ lúc nào. Nếu muốn làm công việc thực sự của một chuyên gia xây dựng phần mềm, bạn cần mở rộng kiểm soát phiên bản trong thiết kế CSDL. Bạn sẽ không thể phục hồi phiên bản 0.784.5 của một phần mềm trong quá trình kiểm tra gỡ lỗi cho khách hàng nếu không tạo được CSDL tương ứng. Nếu các nhà phát triển CSDL đang vui vẻ viết thủ tục lưu trữ, ngừng quá trình thiết kế bảng mà không để lại bất cứ dấu vết gì trong công việc của họ, bạn sẽ gặp phải vấn đề.

Sử dụng công cụ hỗ trợ

CSDL hiện đại thường cung cấp nhiều Bucket, cho phép bạn bổ sung dữ liệu vào. Chúng cũng có nhiều công cụ hỗ trợ, giúp việc quản lý dữ liệu dễ dàng hơn. Như SQL Sever hỗ trợ kiểm tra quá trình bắt đầu của server đang sử dụng truy vấn. CSDL này còn cung cấp một số Wizard nói cho bạn biết chỉ mục nào sẽ thực hiện các truy vấn hiệu quả hơn so với hoạt động tải thực đang thực hiện trên server. Nếu bạn không biết công cụ và tiện ích nào có thể dùng trong CSDL nào và chúng có thể giúp gì cho bạn, hãy đọc thêm nhiều về chúng.

Đừng cho rằng mọi thứ “là cái đinh” chỉ vì bạn có trong tay một cái búa lớn

CSDL ngày nay có xu hướng đưa tất cả dữ liệu lưu trữ vào một ứng dụng. Nhiều ứng dụng đã từng được thử nghiệm xây dựng toàn bộ giao diện người dùng theo hướng siêu dữ liệu. Sau đó lưu trữ siêu dữ liệu với các tham chiếu người dùng trong cùng một Database chứa dữ liệu doanh nghiệp. Đây là một cách tốt để phức tạp hoá đời sống và kỹ năng thực thi. Một số dữ liệu thực sự thuộc về các file cục bộ, không phải nằm trên CSDL client-server qua mạng. Khi lưu trữ dữ liệu, bạn cần đánh giá các vị trí khác nhau có thể đặt chúng (Database, registry, file văn bản thuần tuý, file XML, …) và chọn nơi phù hợp cho từng phần dữ liệu. Đừng đưa nó vào CSDL một cách tự động chỉ vì bạn có trong tay xâu kết nối. Ngày nay, xu hướng sử dụng file XML xuất hiện nhiều hơn là CSDL quan hệ, nhưng nguyên tắc cơ bản thì vẫn vậy.