Giải ngố về SQL – cơ bản nhưng không hề đơn giản

sql-la-gi

SQL là viết tắt của Structured Query Language, nghĩa là ngôn ngữ truy vấn dữ liệu

Có thể coi SQL là ngôn ngữ chung mà bất cứ hệ thống cơ sở dữ liệu quan hệ (RDBMS) nào cũng phải đáp ứng.

Đọc bài phỏng vấn của ITviec với anh Hồng Minh Trí – người có hơn 7 năm làm việc với SQL để biết:

  • SQL là gì? Tầm quan trọng của SQL?
  • Tình huống khiến developer “vỡ mộng” khi mới làm việc với SQL
  • Sai lầm và bài học rút ra của anh Trí
  • Những tài liệu hữu ích để tìm hiểu về SQL và Oracle Database

Xem thêm việc làm SQL Developer trên ITviec

Tiểu sử:

Anh Trí tốt nghiệp đại học Huflit ngành Software Engineering năm 2011. Anh đã từng làm việc cho rất nhiều công ty như FE Credit, Cosatech, BPC Banking Technologies, Amaris và hiện là PL/SQL Developer ở Hansen Technologies.

Tính đến nay, anh Trí đã có hơn 7 năm kinh nghiệm làm việc với SQL, PL/SQL cũng như hệ thống quản trị cơ sở dữ liệu Oracle Database.

Chào anh Trí! Em rất tò mò muốn biết SQL là gì vậy anh?

SQL  là viết tắt của Structured Query Language, nghĩa là ngôn ngữ truy vấn dữ liệu. Có thể coi SQL là ngôn ngữ chung mà bất cứ hệ thống cơ sở dữ liệu quan hệ (RDBMS) nào cũng phải đáp ứng, điển hình như: Oracle Database, SQL Server, MySQL…

Bất kì công ty nào lớn cũng cần xây dựng một hệ thống để lưu trữ cơ sở dữ liệu. Mọi thứ trong cơ sở dữ liệu này sẽ được quy ra thành nhiều bảng, có mối quan hệ với nhau.

Để truy vấn và lấy dữ liệu từ các bảng này (nhằm tổng hợp thành thông tin hữu ích nào đó), người ta dùng đến SQL thông qua các câu query.

Vậy còn PL/SQL mà anh vẫn sử dụng hàng ngày?

PL/SQL là viết tắt của Procedural Language/Structured Query Language – một loại ngôn ngữ thủ tục dùng cho Oracle. Nó là một extension (mở rộng) của riêng Oracle.

PL/SQL ra đời để hỗ trợ thêm cho web service. Nếu như SQL có nhiệm vụ truy vấn đến các bảng để trả về dữ liệu thì PL/SQL sẽ thực hiện những công đoạn tiếp theo như: đóng gói kết quả, xử lý cách hiển thị trên giao diện…

Vì sao SQL lại quan trọng với hầu hết các cơ sở dữ liệu vậy anh?

Khi doanh nghiệp cần một hệ thống để quản trị nhân viên hoặc khách hàng, họ phải thiết kế ra một cơ sở dữ liệu để lưu trữ thông tin. Nếu chỉ lưu trữ ở dạng giấy hoặc excel thì sẽ chứa nhiều rủi ro như bị mất, sửa, xóa…

SQL giúp quản lý hiệu quả và truy vấn thông tin nhanh hơn, giúp bảo trì thông tin dễ dàng hơn.

Ví dụ:  trước đây, bệnh viện thường lưu trữ thông tin bệnh án của bệnh nhân bằng cách viết tay trên hồ sơ giấy. Sau đó, cất giữ hồ sơ trong kho.

Khi cần tìm kiếm hoặc thêm/xóa/sửa thông tin nào đó, em phải mất rất nhiều thời gian để lục lại hồ sơ. Đó là chưa kể đến một số trường hợp sau khi thêm hoặc sửa thông tin, hồ sơ sẽ không còn hợp lệ.

Trong khi, nếu lưu trữ thông tin vào một hệ thống cơ sở dữ liệu, em chỉ cần gõ một câu lệnh SQL ngắn là đã có thể trích xuất được thông tin em cần. Việc thêm/xóa/sửa cũng được thực hiện một cách dễ dàng, nhanh chóng.

Theo như anh nói thì SQL là ngôn ngữ mà các hệ thống quản trị cơ sở dữ liệu đều phải đáp ứng. Có phải chỉ cần học SQL là đủ, những ngôn ngữ truy vấn khác chỉ là ngôn ngữ “rác”?

Thực tế thì mình học cái gì cũng vậy, nên nhìn ra thị trường và tiên đoán xem ngành mình đang làm có còn chỗ đứng trong 5-10 năm nữa hay không, có còn phát triển được nữa hay không… 

Anh thấy SQL ra đời rất lâu đời rồi và anh nhận định là SQL sẽ không bao giờ chết. 

Hầu hết các ngân hàng, công ty tài chính lớn đều đang sử dụng SQL để phục vụ cho hệ thống quản trị cơ sở dữ liệu Oracle. Mà em biết rồi đó, cái gì họ đã đầu tư rất nhiều tiền thì rất ít khi họ muốn thay đổi.

Với lại anh thấy học nhiều ngôn ngữ cũng tốt. Em có thể linh hoạt đáp ứng được xu thế của thị trường vì thị trường không thể đứng im mãi một chỗ được. Nên anh nghĩ rằng các ngôn ngữ truy vấn khác không phải là rác mà rất cần thiết cho developer.

Đọc thêm bài viết: “Tôi không muốn học ngôn ngữ truy vấn rác nào khác, ngoài SQL” – Erik Bernhardsson

Anh có thể nói một chút về công việc hàng ngày của mình được không?

Mỗi sáng, anh thường họp với văn phòng bên Úc để báo cáo tình hình công việc. Chẳng hạn: hôm qua đã làm những gì, hôm nay sẽ làm gì tiếp theo, có khó khăn nào cần hỗ trợ không… rồi mới bắt đầu vào công việc chính.

Bên anh quản lý dự án theo mô hình Scrum, chia ra làm nhiều Sprint khác nhau.

Công việc của anh là giải quyết từng story cụ thể trong từng Sprint mà Scrum Master đã phân bổ cho mọi người. Những story này thường sẽ được chia điểm tùy theo mức độ phức tạp của requirement. 

Ví dụ: story nào đơn giản thì sẽ là 1 point, story nào khó hơn thì là 3 point, 5 point.

Phía khách hàng cũng có ràng buộc là trong một Sprint, mỗi một developer phải làm ít nhất bao nhiêu point đó, chứ không ít hơn được.

Để giải quyết story, thời gian của anh vẫn xoay quanh việc coding và unit test (test lại các chức năng cơ bản sau khi develop một chức năng nào đó), sau đó bàn giao lại cho Tester kiểm thử requirement. 

Thỉnh thoảng, bọn anh cũng sẽ review code chéo cho nhau khi được yêu cầu để đảm bảo mọi người đều có thể cải thiện kỹ năng coding.

Tham khảo thêm: Scrum là gì? Mô hình Scrum vận hành như thế nào?

Có vẻ công việc của một người làm SQL không khác lắm so với các developer thông thường?

Cái này tùy thuộc vào yêu cầu của mỗi công ty. Như anh nói ban đầu, công ty anh làm việc theo mô hình Scrum nên công việc của anh cũng vận hành theo đó.

Vả lại về cơ bản thì SQL giống như một kỹ năng thôi. Hầu như developer nào cũng sẽ làm việc với SQL dù ít hay nhiều.

Chỉ có ngân hàng hoặc những công ty có hệ thống dữ liệu cực lớn như thì họ mới tuyển developer chuyên làm việc với SQL và chỉ duy nhất SQL mà thôi. 

Những người này sẽ thường xuyên trích xuất dữ liệu, tổng hợp các báo cáo, đồng thời đưa ra các phân tích và dự đoán về tình hình tài chính của doanh nghiệp. Ngoài ra, họ phải đưa ra được kế hoạch hoặc định hướng để cải thiện nó.

sql-la-gi

Ngoài giờ làm, anh Trí có sở thích chụp ảnh và đi du lịch đây đó

Hãy kể về một sai lầm mà anh từng mắc phải trong quá trình làm việc?

Anh nghĩ sai lầm thì developer nào cũng sẽ mắc phải. Bên mảng dữ liệu này thì sai lầm lại càng nhiều (cười).

Anh nhớ trước đây có một câu query anh viết chưa thực sự tối ưu. Nó chạy rất chậm và chiếm rất nhiều tài nguyên trong môi trường development. 

Sau đó, anh quyết định thêm Oracle hint (diễn giải dùng để hướng dẫn Oracle chạy theo ý mình) thì thấy code chạy nhanh hơn hẳn, chưa tới 1s đã ra kết quả.

Ỷ y là code của mình ngon rồi, cool rồi, anh mới đưa lên môi trường UAT (User Acceptance Testing). Đây là môi trường để mình test trước khi demo cho khách hàng. 

Lúc này, những nhân viên ở các phòng ban khác cùng truy xuất vào câu query của anh để test thử thì mới thấy vấn đề phát sinh. Nó bị treo, bị đơ toàn tập.

Sau khi tìm hiểu, anh phát hiện nguyên nhân bị lỗi nằm ở chính cái hint mà anh đã thêm vào. Nó chỉ chạy tốt trong môi trường development – nơi chỉ có 1 user là anh đang làm việc. Còn ở môi trường như UAT – nơi có nhiều user hoạt động cùng lúc thì nó lại chạy rất chậm.

Để sữa lỗi này, anh đã bỏ Oracle hint đó đi và tối ưu câu query theo một hướng khác.

Anh đã rút ra được bài học gì sau sai lầm kể trên ạ?

Anh nghĩ là câu query có chạy tốt hay không còn phụ thuộc vào dữ liệu ở mỗi môi trường.

Không nên dựa hoàn toàn vào môi trường development. Dữ liệu ở môi trường này ít hơn hẳn so với môi trường production. 

Nhiều khi test ở môi trường development thấy ổn nhưng khi đưa lên môi trường production lại không hiệu quả.

Kinh nghiệm của anh là nên chủ động test tất cả các trường hợp có thể xảy ra trên nhiều môi trường nhất có thể. Không nên thụ động, chờ Tester la làng thì mới bắt tay vào sửa.

Ví dụ: em cho chạy cùng một câu query trên môi trường development, thấy ổn rồi thì tiếp tục chạy thử trên môi trường ready. Dù đây là môi trường dành cho Tester nhưng mà em cũng nên test thử trước đã. Nếu thấy OK rồi thì gửi mail thông báo cho Tester là code của em đã chạy ngon trên các môi trường này rồi chờ họ xác nhận lại.

Đọc thêm: Tester là gì? Kỹ năng nào cần để trở thành Tester giỏi?

Theo anh, một người muốn làm về SQL nên có những tố chất gì?

Anh nghĩ những bạn nào có tư duy lập trình căn bản thì sẽ làm quen với SQL rất nhanh.

Nghĩa là nếu có nền tảng học về IT tại trường đại học thì khi học một ngôn ngữ mới em sẽ nắm bắt nhanh hơn. Về cơ bản, các ngôn ngữ lập trình chỉ khác nhau về cú pháp. Về bản chất hay logic thì nó khá tương đồng.

Tuy nhiên, điều này cũng không phải yếu tố bắt buộc đâu. Anh thấy có nhiều bạn học kinh tế nhưng chuyển qua học và làm SQL cũng OK lắm. 

Hai là bạn phải có khả năng tìm kiếm bằng tiếng Anh. Hầu hết các tài liệu hay đều được viết bằng tiếng Anh. Có nhiều bài được dịch sang tiếng Việt nhưng mà anh đọc thấy nó kì kì sao đó.

Nói về kinh nghiệm học tiếng Anh của mình thì anh chủ yếu học qua trung tâm thôi. Bây giờ trung tâm đó cũng đóng cửa mất rồi (cười). Anh thực hành nói chuyện với thầy cô người bản xứ, làm bài tập về nhà, coi phim không phụ đề trên Youtube, cứ nghe đi nghe lại nhiều lần như vậy.

Sau này đi làm ở các công ty nước ngoài, anh thường xuyên tham dự các cuộc họp. Khả năng nghe, nói tiếng Anh của anh cũng được cải thiện hơn. 

Ba là bạn phải có tính cẩn thận và tỉ mỉ. Mình làm việc với dữ liệu thì sai một ly là đi một dặm. 

Anh khuyến khích người mới làm về SQL nên thường xuyên đọc lại log server để biết được nguyên nhân sâu xa gây phát sinh lỗi. Biết được nguyên nhân thì lần sau mới tránh lặp lại lỗi tương tự.

Điều gì khiến anh “vỡ mộng” khi mới làm việc với SQL?

Đó là khoảnh khắc nhận ra câu query của mình rất chi là “chuối” (cười).

Khi học ở trường, anh phải tự thiết kế ra cơ sở quản lý dữ liệu riêng, phục vụ cho đề án chứ không có cơ sở quản lý dữ liệu thực tế của doanh nghiệp để thực hành. 

Anh không biết một hệ thống lớn sẽ hoạt động ra sao, chưa được tiếp xúc với performance issue, không biết câu query của mình sẽ chạy nhanh hay chậm khi đưa vào môi trường có lượng dữ liệu lên đến hàng trăm GB…

Rồi đó, đi làm mới nhận ra thực tế phũ phàng. Câu query của mình không hiệu quả, không trích xuất được đúng dữ liệu mình cần.

Đâu là hướng đi cho SQL Developer nói riêng và Database Developer nói chung vậy anh?

Cá nhân anh thấy có 2 hướng phát triển mà các bạn nên tham khảo:

Với những ai có thiên hướng kỹ thuật : có thể phấn đấu để trở thành Data Architect – người thiết kế ra cơ sở dữ liệu cho doanh nghiệp. Muốn làm Data Architect thì yêu cầu bắt buộc là phải nắm rõ được hệ thống trước đã nhé.

Ngoài ra, Data Scientist cũng là vị trí đáng cân nhắc. Ngoài kiến thức về SQL, em còn phải biết về xác suất thống kê và ngôn ngữ lập trình khác, thường là Python. Anh nhận định đây là hướng đi khá hay và tiềm năng, không chỉ với mảng database mà còn với ngành IT nói chung.

Với những ai có thiên hướng về quản lý: đích đến sẽ là Business Analyst hoặc Project Manager.

Đọc thêm: Công việc của Business Analyst là gì? Kỹ năng cần thiết để trở thành Business Analyst?

Những tài liệu học SQL mà anh cảm thấy tâm đắc nhất là gì?

Sách về SQL thì anh thấy có cuốn này phù hợp với người mới bắt đầu:

  • SQL For Dummies: Hướng dẫn cách sử dụng SQL để xây dựng hệ thống quản lý cơ sở dữ liệu, thiết kế database, truy xuất thông tin khi cần…

Còn nếu muốn tìm hiểu riêng về Oracle SQL (cụ thể là PL/SQL), anh có một số gợi ý như sau:

  • Oracle PL/SQL For Dummies: giải đáp tất tần tật các câu hỏi của những người mới bắt đầu về PL/SQL, kèm hướng dẫn thực hành cụ thể.
  • Oracle PL/SQL Programming: người đọc sẽ hiểu hơn về lập trình PL/SQL và có những kiến thức nhất định về cách làm việc hiệu quả với PL/SQL thông qua các ví dụ minh họa.
  • Learn About Oracle Database: không thể bỏ qua trang chủ của Oracle với rất nhiều các kiến thức liên quan đến SQL, PL/SQL và Oracle Database.

Robby2

Bạn muốn tìm hiểu công việc của SQL Developer? Hoặc bạn có nhận định khác về SQL, muốn trao đổi thêm với anh Trí? Hãy chia sẻ ý kiến ở phần bình luận bên dưới nhé.

Và đừng quên tham khảo việc làm SQL Developer tại ITviec!

About the Author:

Social Content Lead
Avatar

Read more...

error: