Thế mod @Duy Luân cho mình hỏi, học cái này mình cần thêm kiến thức j ko, vì ngành mình đi là information system management, mình có qua excel access và đang dùng eêcl khá thường xuyên cho công việc. Thanks mod😃
nguyên tắc cơ bản của database là ko được expose ra cho end-user. Tất cả operation đều phải qua UI frontend --> backend --> db. Cho nên chả việc quái gì bắt end user phải đi học SQL cả. Công ty nào mà bắt bọn finance, marketing truy xuất thẳng vào db để query thì chứng tỏ trình dev cty đó quá cùi.
Ngay cả bản thân backend dev cũng cực kỳ hạn chế truy xuất thẳng vào db, trừ những cái emergency như debug, hotfix trên prod.
@harryhoang1986
Mình xác nhận là có nhé. Mình làm phòng tài chính (riêng với phòng kế toán). Cty mình dùng SAP, 40 dự án với mỗi dự án tầm 1000 khách hàng. Kế toán hằng tháng phải tổng hợp dữ liệu báo cáo về phòng tài chính, nhưng SAP GUI ko đáp ứng đc độ flexible vì mỗi tháng dữ liệu phòng tài chính sẽ xin thêm này nọ kia để phân tích những vấn đề khác nhau. Lúc đấy lại phải xin phòng kế toán, và phòng kế toán lại đổ ra excel, ngồi trình bày lại cho đúng yêu cầu. Bây giờ ước gì đôi bên học SQL sẵn thì đã chẳng phải nhờ vả nhau... Vả lại, dev thì làm quái gì đc vào database prod (thông tin khách hàng) mà cần phải so đo (Cấp độ bảo mật của ISO 27001 - Segmentation of duty, ngay cả pass admin toàn he thong cung đc enrypt và key encrypt đc niêm phong chỉ có BOD được duyệt cho mở). Đó là dữ liệu phân quyền cho các phòng Sale, Finance, Accounting. Vì vậy, dev cũng chẳng giúp đc gì để trích xuất dữ liệu mà phòng tài chính yêu cầu. Chỉ có ngồi xuất SAP ra excel mấy chục nghìn dòng và ngồi sum if, vlook up các kiểu thôi, đương nhiên excel mất rất nhiều thời gian với lượng dữ liệu như vậy
Còn như bạn nói, chắc bạn cũng chưa đạt mức cty lớn cỡ như: sale lo chuyện sale, kế toán lo chuyện kế toán - input và tạo ra dữ liệu, finance cũng có các team lo chuyện vốn, ngân sách, phân tích, planning riêng. Và chính team phân tích, planning là người cần SQL, để làm ra những thông tin cho các phòng ban khác dùng. Ko lẽ bây giờ kêu ông Dev tui cần dữ liệu này nọ để tính IRR, NPV, rồi vì dòng tiền thấp quá, kêu ông đấy xuất ra lịch thanh toán của khách, mà loại được chiết khấu thanh toán nhau bao nhiu % ấy, rồi thấy vấn đề lại kêu ông dev/kế toán, lọc ra giúp tôi KH nào đc khuyến mãi cục này cục kia, rồi lại kêu anh lọc giúp tôi KH nào là KH thân thiết etc... Mỗi lần xin như vậy mất 1 ngày đi, thì chắc 1 tháng đc một bài phân tích BCQT cho BQT đọc, thì mọi chuyện đã giải quyết xong xui
@NinjaVN
Đấy là chưa kể KH chỉ là một phần, rồi tiền đầu tư chạy đi đâu, tiền commission chạy đi đâu, vốn hóa lãi vay có đúng ko, chi phí accrue có đúng ko, doanh thu lệch thời kỳ như nào, v.v. và mây mây, đòi hỏi bộ phận chuyên về phân tích digging dữ liệu, và SQL giúp cho việc digging đấy trở nên đơn giản hơn. Một cái report system đc fix sẵn chỉ đủ khả năng truy xuất theo template đc set, hiển thị đủ những gì mà dev cho hiển thị khi setup ban đầu, còn digging để tìm hiểu vấn đề là chuyện khác
@NinjaVN
Bên tôi dùng cloud services. Mỗi kỳ báo cáo lại tạo report/query (tự viết), xong export sang Excel. Chứ ko trông chờ vào mấy cái report có sẵn của hệ thống đc.
@allstreet
Tài liệu Power Query free nhiều lắm bác, vd tham khảo. Vấn đề là mỗi CSDQ thì query syntax khác nhau xiu xíu, và Power Query nó sẽ xử giúp mình vụ đấy, để rảnh đầu làm cái khác. Làm data nhiều mà dựa vào mỗi SQL, không có công cụ ETL (Extract-Transform-Load) nào khác thì .. nông thôn lắm 😆.
@Duy Luân
Bác yên tâm :D, bên cạnh phần query data từ một hay nhiều database/table hay nhiều nguồn (vd HTML table), M language còn cho phép làm data manipulation kiểu một tờ giấy gập làm 4, cắt chéo thành 16 phần, ghép thành tờ giấy mới. Còn xét về tốc độ query thì không chậm hơn SQL đâu. Cheerr :D.
Đọc bài từ đầu đến cuối, hiểu nội dung, thấy những kiến thức này sao hấp dẫn quá và nếu mình làm chủ được những kiến thức này thì cảm giác sẽ rất tuyệt vì mình có phương pháp để giải quyết được những điều vô cùng mất thời gian và công sức.