Có còn cần viết SQL không?

Với rất nhiều công cụ ORM cho hầu hết các ngôn ngữ hiện đại, vẫn còn trường hợp sử dụng để viết và thực thi SQL trong một chương trình, trong một ngôn ngữ / môi trường hỗ trợ chúng? Nếu vậy tại sao?

Để rõ ràng: Tôi không hỏi về việc các lập trình viên có cần biết SQL hay không, nếu tôi nên có một công cụ SQL trên máy tính để bàn của mình. Tôi đang hỏi cụ thể tại sao tôi có thể có nó trong mã (hoặc cấu hình, hoặc bất cứ điều gì) trái ngược với ORM.

• Bạn cảm thấy thoải mái hơn khi viết SQL để truy vấn dữ liệu so với việc bạn đang viết mã thủ tục.
• ORM của bạn, trong khi nhìn đẹp, sẽ tạo ra SQL chậm khủng khiếp trong một số lĩnh vực quan trọng.
• Bạn cần tận dụng chức năng được hiển thị bởi RDBMS của bạn mà không / không thể có sẵn thông qua ORM của bạn.
• Mỗi khi bạn gõ SELECT * FROM..., Chúa giết chết một con mèo con. Và bạn ghét mèo con.
• Bạn không sử dụng ORM, OOP hoặc ngôn ngữ hiện đại.

Viết SQL phức tạp

ORM là tuyệt vời cho những điều cơ bản. Tuy nhiên, đối với các tình huống phức tạp, bạn sẽ phải viết SQL.

Vì vậy, trong ngắn hạn, chắc chắn là có nhu cầu về SQL và nó sẽ luôn luôn như vậy.

• Lượt xem
• Gây nên
• Những ràng buộc
• Gói (SSIS, DTS, v.v.)
• Bất cứ lúc nào bạn cần kiểm soát luồng thực thi chính xác

ORM không giúp bạn xây dựng, điều chỉnh hoặc tự động hóa cơ sở dữ liệu. Nó chỉ cung cấp cho bạn một cách khác để tương tác với cơ sở dữ liệu khi bạn đã thực hiện tất cả những thứ đó.

Chắc chắn rồi:

• Nói chung ORM gói gọn rất nhiều, nhưng cuối cùng bạn nên biết những gì xảy ra đằng sau hậu trường. Điều này là rất quan trọng cho hiệu suất và khả năng mở rộng. Mặc dù bên trong ứng dụng tôi không viết nhiều SQL như vậy nhưng tôi biết đại khái là SQL hoặc DDL trông như thế nào.
• SQL trực tiếp thường rất hay để viết các truy vấn chỉ đọc. Dễ dàng hơn nhiều để xây dựng nó trong ngôn ngữ truy vấn ORM và bạn cũng có thể giới hạn tập kết quả (ví dụ: 'chọn id từ .....').
• ORM hoàn toàn không nên tránh xa SQL. Tôi sử dụng SQL rất nhiều cho các truy vấn đặc biệt trực tiếp trên máy khách DB (như mysql-client). Nó cung cấp cho bạn giao diện thống nhất rất đẹp và chức năng nhóm.

Các ORM tồn tại do sự không phù hợp trở kháng giữa các triển khai DB quan hệ phổ biến và các tính năng ngôn ngữ OO của chúng tôi. Chúng chỉ là một cây cầu, nhưng hầu hết mọi người đối xử với SQL như pho mát Limburger trong tủ lạnh.

Nếu bạn có thể nói một cách chính đáng rằng bạn sẽ luôn sử dụng ORM hoặc lớp truy cập dữ liệu trừu tượng khác thay vì coi SQL / thủ tục lưu trữ / lượt xem như một giao diện hạng nhất, thì bạn có thể sẽ tốt hơn nếu không chạm vào SQL.

Trong thực tế, tôi chưa bao giờ thấy một dự án ORM thuần túy nào không yêu cầu ít nhất SQL để truy vấn cơ sở dữ liệu để xác thực cuối cùng.

ORM là một công cụ trong hộp công cụ lập trình viên. Họ có những vấn đề riêng của họ. Một số ví dụ:

• Không thể kiểm soát sql
• Bị vấn đề n + 1

Nếu bạn biết những gì bạn đang làm, bạn có thể sử dụng ORM một cách hiệu quả để thay thế phần lớn mã loại CRUD của bạn. Mặc dù vậy, chúng không hiệu quả đối với những thứ phức tạp, chúng khó điều chỉnh hiệu năng (bạn có biết rằng hiệu suất là một trong những phần quan trọng của thiết kế cơ sở dữ liệu, không phải mô phỏng các đối tượng) và chúng hết sức kinh khủng và nguy hiểm trong tay một người không Không hiểu hoặc tự viết SQL.

Tôi cũng muốn chỉ ra rằng báo cáo phức tạp không dễ thực hiện với ORM. Và hơn nữa nếu bạn không học SQL đơn giản trong các công cụ dễ kiếm, làm thế nào bạn có thể đến điểm mà bạn có thể viết SQL phức tạp để báo cáo? Tôi chưa bao giờ làm việc trong một ứng dụng không có nhu cầu báo cáo và thường khá phức tạp.

Phần lớn các ORM không hữu ích cho các quy trình BI hoặc ETL. Chúng cũng không hữu ích cho các truy vấn quản trị viên cơ sở dữ liệu hoặc để tìm thông tin trong các bảng kiểm toán và hoàn tác một bộ thay đổi cơ sở dữ liệu cụ thể. Có rất nhiều điều vẫn được thực hiện hiệu quả nhất với SQL. Ứng dụng truy vấn cơ sở dữ liệu là một phần nhỏ của những gì cần truy vấn nó trong môi trường Doanh nghiệp.

Tôi cũng thấy nhiều câu hỏi về cách thực hiện điều gì đó bằng ORM mà người đăng đã biết cách thực hiện trong SQL. Thật tuyệt khi học những điều mới, nhưng khi chúng gây ra thêm thời gian và nỗ lực mà không đạt được thực sự so với phương pháp ban đầu (và thường là mất hiệu suất thực sự), tại sao bạn lại sử dụng chúng mà không phải là "thời trang" ngay bây giờ.

Đôi khi, khách hàng chỉ muốn một truy vấn nhanh chóng và dễ dàng để trả về dữ liệu cho báo cáo, xuất, dữ liệu, v.v. và muốn chờ đợi toàn bộ chương trình được phát triển.

Ngoài ra, một lập trình viên SQL giỏi luôn có thể viết SQL nhanh hơn, hiệu quả hơn bất kỳ ORM nào tôi đã sử dụng. Ngoài ra, tôi đã tìm thấy rất nhiều người chỉ có điểm ORM cho các thủ tục được lưu trữ - thực sự bỏ qua các lợi ích của ORM vì ORM không tuyệt vời cho các quy trình phức tạp.

Ngoài ra, khi sử dụng cơ sở dữ liệu như Oracle với ngôn ngữ thủ tục rất phong phú và mạnh mẽ, bạn có thể làm rất nhiều việc mà không cần phải có "chương trình". PL / SQL trên Oracle trong tay phải rất nhanh và hiệu quả.

Nếu bạn muốn sử dụng một cơ sở dữ liệu cho mình, có. Hầu hết các ORM mà tôi đã cố sử dụng chỉ không đủ hoặc không bao gồm cơ sở dữ liệu của tôi. Bên cạnh đó, bạn sẽ khắc phục sự cố hoặc viết các truy vấn tùy chỉnh không được bảo hiểm như thế nào?

Nó vẫn được yêu cầu để viết trình kích hoạt và thủ tục lưu trữ. Hiện tại các thủ tục được lưu trữ có thể không còn được ưa chuộng, nhưng chúng vẫn rất hữu ích trong một số trường hợp. SQL cũng có thể được yêu cầu cho một số phép nối nhiều bảng đặc biệt có lông.

Có, bạn có thể tránh viết SQL. Nhưng cuối cùng bạn sẽ viết HQL (hoặc Linq, hoặc DQL ...)!

Nghiêm túc mà nói, tôi là một fan hâm mộ lớn của ORM và tôi nghĩ người ta có thể tránh sử dụng SQL thuần túy trong hầu hết thời gian. Nhưng chúng ta phải nhớ rằng một ORM chỉ là một sự trừu tượng hóa lớn và tất cả các khái niệm trừu tượng lớn đều bị rò rỉ ...

(Nhưng về vấn đề N + 1: đây là liên quan đến tải lười biếng và hầu hết các công cụ ORM có một số cách yêu cầu tải háo hức, do đó tránh được vấn đề cụ thể đó.)

ORM sẽ chỉ đưa bạn đến một số điểm. Nhưng có những trường hợp khi bạn phải thực hiện một truy vấn thực sự phức tạp, với các phép nối phức tạp, truy vấn con, liên hiệp, trừ, các hàm phân tích, v.v. Đó là khi bạn cần SQL. Nhưng làm thế nào bạn có nghĩa vụ phải viết các truy vấn phức tạp khi bạn để lại tất cả các truy vấn đơn giản cho ORM?

Ngay cả khi bạn không cần phải viết nó vào mã của mình, nó vẫn khá tiện để có thể sử dụng nó khi bạn có quyền truy cập đầu cuối vào máy chủ cơ sở dữ liệu.

Ngoài ra, hầu hết những gì làm cho lập trình một thách thức đang làm việc trong những hạn chế mà bộ cuộc sống Mỹ-thường chúng tôi đang làm việc với mã cũ, hoặc phiên bản cũ của cơ sở dữ liệu và không có cơ hội để cài đặt các thư viện ORM mới nhất cho bất cứ ngôn ngữ chúng tôi làm việc với. Trong tình huống đó, bạn sẽ cần bất kỳ công cụ theo ý của bạn.

Thời gian còn lại bạn có thể không cần SQL cho công cụ CRUD của mình, nhưng có nhiều thứ hơn với SQL so với các truy vấn CHỌN, CHERTN, CẬP NHẬT và THAM GIA cơ bản. Bạn có thể làm những điều rất thông minh với nó và mặc dù bạn có thể không sử dụng chúng thường xuyên, thật hữu ích khi biết chúng là gì.

Càng ngày, tôi nghĩ rằng chúng ta sẽ thấy mình trong một thế giới SQL bài, tuy nhiên - hầu hết các dịch vụ Đám mây sử dụng lưu trữ bảng không phải là sql và đối với loại CRUD đơn giản, toàn bộ sức mạnh của SQL là không cần thiết. Nhưng điều đó không có nghĩa là sẽ không có giá trị trong việc hiểu nó.

Ngoài ra, tất nhiên, ai đó phải biết đủ để viết một hệ thống ORM tốt hơn nếu những hệ thống hiện tại không hoạt động nhiều. Nó sẽ giúp họ nếu họ biết SQL ...

Để xây dựng các ứng dụng web quy mô lớn, nó hoàn toàn không cần thiết và có thể khiến mọi thứ trở nên căng thẳng và lãng phí thời gian hơn nhiều so với mức cần thiết. Lý do cho điều này là vì bất kỳ ứng dụng quy mô lớn nào cũng nên sử dụng lớp lưu giữ bộ nhớ (trong RAM), là bộ phận lưu trữ bộ nhớ của DB thường được sử dụng.

Nếu bạn phải làm việc với các thiết bị di động, v.v. không có nhiều bộ nhớ để làm việc, nơi ứng dụng đang được lập trình đang chạy dưới dạng "ứng dụng khách" hoặc ứng dụng độc lập trên thiết bị di động, máy tính bảng, v.v. những thứ như sử dụng SQL vẫn còn phổ biến và rất quan trọng vì bộ nhớ trên thiết bị quá nhỏ đến mức bạn không thể lưu trữ nhiều thứ trong bộ nhớ.

Độ phức tạp và số lượng SQL tôi viết không đủ để tạo ra một khung ORM hợp lý.

(Tôi viết SQL có thể mỗi tháng một lần, nếu)

Tôi đã bắt gặp nhiều quân đoàn lớn với các DBA, những người chủ động sợ các nhà phát triển sử dụng các công cụ ORM.

Họ là những DBA có liên quan đến điều chỉnh và hiệu suất.

Và vâng, các công cụ ORM có thể được quản lý để làm những việc như thế này, nhưng tôi đã thấy những nơi mà họ sẽ chỉ chấp nhận một quy trình được lưu trữ (Sql Server) và sẽ hỏi bạn về những gì bạn đang làm trong đó.

Ngoài ra, các công cụ ORM có thể bị lạm dụng nghiêm trọng và tạo ra Sql kém như chính việc viết Sql.

Một biggie - DDL và di chuyển cơ sở dữ liệu. Đôi khi bạn cần khâu tay những thứ đó để cập nhật mọi thứ mà không phá vỡ dữ liệu hiện có.