SQL có quan trọng không nếu tôi biết các khung ORM tốt? [đóng cửa]

Tôi không có bất kỳ kinh nghiệm nghiêm túc nào về SQL và tôi thậm chí ghét viết SQL thay vì LINQ. Tôi đủ hạnh phúc với ORM.

Từ quan điểm của nhà tuyển dụng và ngành, việc biết SQL có quan trọng không? Tôi có phải thành thạo về nó? Các công ty thích SQL thuần túy hơn các khung ORM có phải là "khủng long" trong thế giới lập trình không?

Điều này thật khó để giải thích với nhiều lập trình viên, bởi vì nếu bạn chỉ biết SQL cơ bản thì nó thực sự không mang lại cho bạn nhiều lợi thế so với cái nạng của ORM. Tuy nhiên, các khái niệm SQL nâng cao hơn là một phần quan trọng của sự khác biệt giữa các ứng dụng chỉ hoạt động so với các ứng dụng có chất lượng cao (đặc biệt, nhanh và đáng tin cậy).

Tôi giả sử ai đó thiết kế cơ sở dữ liệu cho bạn, bởi vì làm điều đó mà không biết bất kỳ SQL nào chỉ là vượt quá nhạt. Nhưng ngay cả khi bạn chỉ đang phát triển chống lại họ, đây chỉ là một danh sách một phần của tất cả những điều mà ORM vẫn có xu hướng làm kém hoặc hoàn toàn không:

• Truy vấn đệ quy và / hoặc phân cấp
• Các tham số tùy chọn (đặc biệt là dịch chúng thành các biến vị ngữ)
• Kiểu dữ liệu do người dùng định nghĩa
• Các loại dành riêng cho nền tảng (phân cấp SQL và TVP, mảng Oracle và các bảng lồng nhau, v.v.)
• Batch chèn / cập nhật / uperts / xóa
• Gợi ý chỉ số
• Gợi ý khóa (đặc biệt là cập nhật khóa và đọc bẩn)
• Xử lý lỗi
• Các phép nối ngoài - kết quả của chúng đặt ánh xạ kém vào mô hình OOP, nhiều ORM có ngôn ngữ truy vấn riêng nhưng tương tự như việc biết chính SQL;
• Mô đun hóa thông qua thủ tục được lưu trữ và UDF, đặc biệt là các truy vấn UDF nội tuyến và CROSS ỨNG DỤNG
• Sử dụng OUTPUT / RETURNING để sắp xếp dữ liệu vào nhiều bảng
• Truy vấn phân trang hiệu quả
• Truy vấn dựa trên các chức năng cửa sổ (rownum, xếp hạng, phân vùng)

Danh sách này cứ lặp đi lặp lại - rất nhiều trong số đó là những điều mà một DBA mới làm quen chưa bao giờ phải làm, và một nhà phát triển người mới thậm chí chưa bao giờ nghe nói đến - nhưng chúng rất quan trọng trong các ứng dụng quy mô lớn hơn.

Các ORM thực sự tuyệt vời trong việc tăng tốc mã SQL thực sự nhàm chán - đó là tất cả các CRUD lặp đi lặp lại và ánh xạ và mã hệ thống ống nước khác, vì vậy hoàn toàn không có gì xấu hổ khi sử dụng chúng và không nghe bất cứ ai nói rằng chúng là xấu xa. Nhưng bạn chắc chắn vẫn cần phải học và có, thậm chí thành thạo SQL và sẵn sàng thả xuống các lệnh / truy vấn DB thô khi ORM không kéo theo trọng số của nó.

Chắc chắn rồi! SQL vẫn là ngôn ngữ chung của cơ sở dữ liệu và mặc dù bạn có thể làm rất nhiều với ORM, bạn phải hiểu SQL để hiểu các quyết định ORM đưa ra và SQL mà chúng tạo ra. Ngoài ra, vẫn còn rất nhiều điều bạn phải làm với sql tùy chỉnh và các thủ tục được lưu trữ là tốt. Xin lỗi, không có bữa trưa miễn phí.

Có, bạn vẫn cần biết SQL. Các ORM là một sự trừu tượng hóa rất rò rỉ và không cung cấp quyền truy cập vào toàn bộ sức mạnh của SQL. Đối với các ứng dụng đồ chơi, bạn có thể ổn với kiến ​​thức SQL hạn chế. Đối với các ứng dụng doanh nghiệp, bạn sẽ phải hiểu cơ sở dữ liệu để có được hiệu suất tốt từ ORM. Ngoài ra, có rất nhiều nhiệm vụ dễ dàng thực hiện với SQL hơn là với ngôn ngữ ứng dụng. Tôi đã thấy các lập trình viên Java dành nhiều ngày để viết mã để làm một cái gì đó có thể được mã hóa bằng SQL trong một giờ. Kiến thức SQL rất có giá trị đối với bất kỳ ai viết các ứng dụng sử dụng cơ sở dữ liệu quan hệ.

Kỹ năng SQL là một kỹ năng phải có trong CNTT ngày nay. LINQ là một công nghệ duy nhất của Microsoft. Việc sử dụng SQL vượt xa sự phát triển ứng dụng web và máy khách / máy chủ. Bạn không thể mô hình hóa cơ sở dữ liệu và làm ETL nếu bạn không giỏi về SQL. Bạn có thể không cần phải thành thạo các phương ngữ SQL được sử dụng trong ORACLE và SQL Server cho các sản phẩm Kho dữ liệu của họ, nhưng bạn nên biết SQL chuẩn. Khái niệm cơ bản về SQL rất đơn giản, có rất nhiều tài liệu để bạn bắt đầu.

Nếu bạn đang tương tác với cơ sở dữ liệu SQL, bạn phải hiểu SQL mà ORM đang tạo. Bạn phải hiểu các khái niệm vốn có trong cơ sở dữ liệu SQL và bạn phải hiểu ORM của bạn không thể làm gì cho bạn. ORM làm cho cuộc sống dễ dàng hơn (và vâng, tôi nghĩ rằng làm việc mà không có ai đủ điều kiện bạn là một con khủng long trong nhiều trường hợp), nhưng chúng là công cụ (để trừu tượng hóa những gì bạn biết), không phải nạng (để ngăn bạn học).

Nếu bạn từ chối học SQL, thì bạn không có kinh doanh gì khi chạm vào cơ sở dữ liệu SQL, dù có hoặc không có ORM, và bạn nên tìm một loại công việc khác.

Tôi sẽ thừa nhận rằng tôi là một người hâm mộ ORM khó tính và đã giảng về lợi ích của ORM trong nhiều năm và có rất nhiều điều để nói về lý do tại sao ORM lại bỏ qua SQL.

NHƯNG...

Tôi phải thừa nhận SQL là hoàn toàn và hoàn toàn cần thiết trong thế giới thực và mọi nhà phát triển nên có hiểu biết tốt về SQL.

Procs SQL nhanh hơn ORM trong hầu hết các trường hợp. Mặc dù bạn có thể lạc quan đầu ra ORM trong hầu hết các trường hợp cũng làm cho nó đến gần với các procs SQL.

Đôi khi, bạn yêu cầu một số SQL nhiệm vụ nặng nề để có được kết quả mà bạn yêu cầu và các truy vấn quái vật này dễ dàng hơn và nhanh hơn để tạo trong các procs SQL.

Chỉ cần hai bit của tôi.

Sẽ đến lúc bạn phải tối ưu hóa một cái gì đó phức tạp mà ORM đang tạo ra. Tại thời điểm đó, bạn thường có một truy vấn cực kỳ phức tạp để phá vỡ. Nếu bạn chưa bao giờ học những điều cơ bản, làm thế nào bạn có thể mong đợi bắt đầu học SQL với những thứ nâng cao? Bạn sẽ không đủ hiểu để bắt đầu. ORM trong tay một người hiểu SQL - một công cụ tốt. Các ORM trong tay một người hoàn toàn không biết SQL - thảm họa đang chờ xảy ra.

Một trong những lý do tại sao SQL rất quan trọng để hiểu cơ sở dữ liệu là các lập trình viên ứng dụng không tự nhiên nghĩ về các tập dữ liệu. Nhưng cách duy nhất cơ sở dữ liệu hoạt động hiệu quả là theo bộ. Bạn cần học cách suy nghĩ theo bộ trước khi bạn cố gắng sử dụng ORM.

Tôi thấy mình tự buộc các truy vấn trong khung ORM thường xuyên hơn không. Và trong khi hầu hết đều có ngôn ngữ truy vấn riêng, tất cả đều được truyền cảm hứng từ sql, mã được chuyển thành sql và bạn cần hiểu điều gì sai bằng cách đọc sql đó khi (không phải, khi nào) mọi thứ bị sai hoặc hoạt động kém.
Vì vậy, ngay cả khi bạn không viết sql trực tiếp, hiểu nó vượt quá mức cơ bản (mặc dù bạn có thể không cần phải học những điều về cách viết thủ tục lưu trữ, trình kích hoạt, v.v. nếu tất cả những gì bạn sẽ làm là truy cập cơ sở dữ liệu) nên biết ngôn ngữ đủ để hiểu mã được tạo và điều chỉnh nó khi cần thiết.

Trước khi tôi nói về câu hỏi, một chút giới thiệu trước; Tôi yêu các ORM. Và tôi ghét SQL. Tôi yêu các ORM vì chúng che giấu sự lộn xộn không thân thiện của người dùng với SQL và cung cấp một cách xử lý tích hợp ngôn ngữ tốt với cơ sở dữ liệu.

Tuy nhiên tôi phải thừa nhận rằng SQL có rất nhiều lợi ích, với cái lớn hơn là độ chính xác. Tôi có thể tranh luận khá nhiều về sự phức tạp của một truy vấn SQL, mà không có kiến ​​thức chi tiết về lược đồ cơ sở dữ liệu cơ bản, chỉ bằng cách đi qua truy vấn. Do đó, khi tôi sử dụng SQL, tôi luôn cảnh giác và tôi luôn có một trực giác về nơi mà sự phức tạp của một thành phần đang hướng đến.

Mặt khác, khi sử dụng ORM, tôi bị choáng ngợp bởi sự dễ dàng tích hợp cơ sở dữ liệu, đến nỗi tôi thực sự quên rằng thậm chí còn có một cơ sở dữ liệu. Điều này đã làm tôi khó chịu nhiều lần. Nhiều lần trong quá khứ, tôi đã gọi các phương thức ORM trông ngây thơ, rằng đằng sau hậu trường gọi các cơ sở dữ liệu khổng lồ và đáng sợ tham gia, phá hủy hiệu suất.

Đó là lý do tại sao đối với tôi, sự thật nằm ở đâu đó ở giữa. Tôi thích sử dụng ORM và tôi sẽ tiếp tục làm như vậy, nhưng tôi phải cẩn thận hơn và luôn nghiên cứu ý nghĩa (ở cấp độ SQL) của bất kỳ cuộc gọi phương thức ORM nào. Biết ý nghĩa của một lớp trừu tượng là vàng nguyên chất trong doanh nghiệp này, và biện minh cho việc sử dụng trừu tượng. Bất cứ điều gì khác, giống như tự bắn vào chân mình.

Nếu tất cả những gì bạn cần làm chỉ tương tác với cơ sở dữ liệu mặc dù ứng dụng bạn đang xây dựng, có lẽ bạn không cần đến nó. Tại một số công ty nhỏ hơn hoặc các nhóm phát triển, bạn có thể phải thực hiện một số hỗ trợ. Việc kết nối với cơ sở dữ liệu của khách hàng sẽ dễ dàng hơn rất nhiều và chạy một vài câu lệnh sql để xem điều gì đang xảy ra với dữ liệu của họ.

Ngay cả với một ORM tốt, trưởng thành, bạn chắc chắn sẽ gặp phải tình huống phát ra một số SQL không hiệu quả và nó sẽ giúp cuộc sống của bạn dễ dàng hơn rất nhiều nếu bạn có thể tìm hiểu những gì đang diễn ra trong SQL được tạo. Điều đó nói rằng, nếu bạn rất thành thạo ORM và biết cách sử dụng một trình lược tả cho DB bạn chọn, bạn có thể dễ dàng "giả mạo cho đến khi bạn tạo ra nó".

Câu trả lời cho tất cả các loại câu hỏi này ("tôi có cần biết X không?") Là "học nó ngay lần đầu tiên bạn cần nó, nếu bạn sẽ cần nó".

Mặc dù điều quan trọng là không rơi vào cái bẫy làm việc kém hiệu quả vì bạn không nhận thức được hoặc không sẵn sàng học cách hiệu quả để thực hiện chúng.

Trong trường hợp cụ thể này, ví dụ, bạn sẽ làm gì nếu bạn nhận ra rằng có một lỗi trong chương trình của bạn khiến PostCounttrường của bảng người dùng của bạn đôi khi không chính xác.

Bạn sửa lỗi và bây giờ bạn phải cập nhật PostCount cho tất cả người dùng. Bạn làm nó như thế nào?

Nếu bạn viết một đoạn script nhỏ bằng ORM để làm điều này thì bạn đang rất kém hiệu quả; một truy vấn SQL rất đơn giản sẽ làm.

Vì những tình huống này khá phổ biến, tôi sợ rằng bạn rơi vào cái bẫy được mô tả ở trên!

Có, bạn vẫn cần SQL.

Đừng nhảy vào giả định rằng một cái gì đó "cũ" bằng cách nào đó không đáng để xem xét. Vì vậy, các công nghệ "di sản" là những công nghệ vẫn còn tồn tại sau khi đứng trước thử thách của thời gian. Chúng tôi không gọi máy tính Wang là "di sản", chúng đã thất bại và biến mất.

Nếu bạn hỏi tôi có làm phiền tôi rằng ngân hàng của tôi có thể đang sử dụng COBOL trên máy tính lớn hay IBM i không? Tuyệt đối không. Đây là đá rắn, cố gắng và công nghệ thực sự. Đoán xem, họ chủ yếu sử dụng SQL SQL. Tôi hạnh phúc hơn nhiều khi tin tưởng vào tiền của mình ở đó, hơn là trong phần mềm được phát triển theo ngôn ngữ thời thượng của tháng.

Những con khủng long tồn tại trên trái đất này lâu hơn nhiều so với con người chúng ta đã tồn tại. Và nếu bạn đọc Công viên kỷ Jura (vâng, sách hay hơn phim) thì tôi hỏi bạn, bạn có thực sự muốn đối mặt với một gói Velociraptors siêu thông minh, hay một T-Rex bướng bỉnh không bao giờ bỏ cuộc? Đừng để bị cắn bằng cách đánh giá thấp "khủng long". ;-)

Ngoài các trò chơi và nghiên cứu (chủ yếu là thống kê) mà tôi không có kinh nghiệm, có vẻ như việc truy cập và vận hành cơ sở dữ liệu là một trong số ít các quyết định sai dẫn đến hiệu suất rất lớn. Tôi là người tin tưởng mạnh mẽ vào sự trừu tượng hóa cơ sở dữ liệu mạnh mẽ hơn trong mã và tôi tin rằng linq, liên kết các hoạt động cơ sở dữ liệu với ngôn ngữ lập trình, cung cấp cho bạn tất cả các công cụ của ngôn ngữ (kiểm tra kiểu, kiểm tra cú pháp, tất cả những điều bạn thích về ngôn ngữ lập trình của bạn) trong khi vẫn cung cấp cho bạn nhiều sức mạnh để làm những gì bạn muốn là hoàn toàn tuyệt vời. Thật không may, nó vẫn không luôn luôn hoạt động. Điều đó có nghĩa là, nếu lớp trừu tượng bị sai tối ưu hóa và bạn có thể đợi trong vài giây thay vì micro giây hoặc vài phút thay vì giây cho kết quả của bạn. Vì đây là những thời điểm rất đáng chú ý, bạn phải tối ưu hóa chúng đi, hoặc ứng dụng của bạn không "hoạt động": hiệu suất trở thành vấn đề lớn nhất của ứng dụng của bạn. Điều đó có nghĩa là bạn phải đến gần kim loại hơn và tối ưu hóa tay.

Khi chúng ta đi đến điểm thao túng các bộ dữ liệu lớn, ví dụ 3 ms khi thực hiện bằng tay và 100 ms khi bạn để lớp trừu tượng làm điều đó cho bạn, bằng mọi cách, hãy để lớp trừu tượng xử lý nó cho bạn, bởi vì bạn có thể chậm hơn 30 lần, nhưng bạn vẫn (có thể, đối với hầu hết các ứng dụng) đủ nhanh. Tuy nhiên, thực tế của tình huống là khi bạn đang xem xét các giải pháp được tối ưu hóa bằng tay trong đó bạn có thời gian phản hồi 200 ms và khi lớp trừu tượng xử lý nó cho bạn, thuật toán sẽ "chỉ cần 10 lần thực hiện", bạn có một lần thực hiện Trì hoãn 2 giây, và sau đó bạn quan tâm rất nhiều, vì nó đi từ không quá nhanh, đến chậm một cách đau đớn. Thấy rằng các giải pháp cơ sở dữ liệu quan hệ không có quy mô tốt, Tôi không nghĩ rằng điều này sẽ được giải quyết trong hai hoặc ba năm. Điều này có nghĩa là bạn sẽ vẫn phải xuống kim loại trong một thời gian khá lâu khi nói đến cơ sở dữ liệu lớn hơn, hoặc ứng dụng của bạn sẽ rất chậm, nó không thể đứng vững trước các đối thủ cạnh tranh.