Mười lỗi lớn nhất các nhà phát triển hay mắc phải với CSDL
Thú Tư, 23.05.2007, 08:48am (GMT+7)
Thế
giới phần mềm luôn phát triển không ngừng với những kiểu mẫu mới, thời
thượng hơn, trang nhã hơn, đa chức năng hơn. Đã qua lâu rồi cái thời
sản phẩm IT chỉ là những cái máy “cục mịch”, có mỗi nhiệm vụ thực hiện
chức năng theo mã hoá của người lập trình. Bây giờ, bên cạnh khả năng
hoạt động người ta còn quan tâm nhiều đến kiểu dáng, giao diện đẹp mà
tiện lợi. Nói vậy nhưng, cũng có không thứ đáng để tâm mà từ trước đến
nay chẳng hề được thay đổi. Đôi khi đó lại là các thói
quen xấu của người quản trị, nhất là trong việc sử dụng cơ sở dữ liệu.
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.
QuanTriMang, Developer
|