Những lợi thế để sử dụng các trình xây dựng truy vấn SQL là gì?

Có bất kỳ lợi thế nào khi sử dụng trình xây dựng truy vấn, thay vì sử dụng SQL thô không?

Ví dụ

$q->select('*')
  ->from('posts')
  ->innerJoin('terms', 'post_id')
  ->where(...)

vs

SELECT * FROM posts WHERE ...

Tôi thấy rằng nhiều khung sử dụng các lớp trừu tượng này, nhưng tôi không hiểu được lợi ích.

Sự trừu tượng của việc viết SQL thông qua một khung công tác, tóm tắt.

Viết SQL bằng tay không phải là tất cả xấu, nhưng bạn bắt đầu gặp vấn đề với việc trốn thoát và vệ sinh và điều này biến thành một mớ hỗn độn. Một lớp trừu tượng có thể xử lý tất cả những điều này đằng sau hậu trường cho phép mã của bạn sạch sẽ và không có nhiều mysql_real_escape_string()cuộc gọi hoặc tương tự.

Ngoài ra, điều này mang đến khả năng kế toán cho các phương ngữ khác nhau của SQL. Không phải tất cả các cơ sở dữ liệu đều được xây dựng giống nhau và có thể có các biến thể trong từ khóa hoặc cú pháp của một chức năng nhất định. Sử dụng một lớp trừu tượng mang lại khả năng tạo cú pháp chính xác cho biến thể của bạn một cách linh hoạt.

Mặc dù một lớp trừu tượng có thể giới thiệu một cú đánh hiệu năng, nhưng nhìn chung nó không đáng kể so với độ sạch và độ mạnh của mã mà bạn nhận được.

Những người xây dựng truy vấn là một con thú cưng của tôi, vì vậy tôi đã viết Framework (Apeel) của riêng tôi để tránh sử dụng chúng!

Nếu bạn sử dụng PDO (mà tôi chắc chắn khuyên bạn nên làm) thì việc xác nhận đầu vào được xử lý cho bạn.

Giống như người khác đã nói, mặc dù chúng giúp chuyển đổi giữa các cơ sở dữ liệu dễ dàng hơn nhưng chúng có xu hướng hỗ trợ chức năng "Mẫu số chung thấp nhất" và sẽ không hỗ trợ hoặc có hiệu suất kém hơn cho các tính năng nâng cao hơn.

Tôi đã phát triển các hệ thống với cơ sở dữ liệu từ khoảng năm 1986 và trong thời gian đó tôi hiếm khi bắt gặp một công ty thực sự thay đổi cơ sở dữ liệu mà họ sử dụng ngoài khi họ cần hiệu suất tốt hơn. Nếu bạn đang thay đổi cơ sở dữ liệu để có hiệu suất tốt hơn thì sẽ có ý nghĩa hơn khi dành thời gian tối ưu hóa các truy vấn của bạn để tận dụng tốt nhất cơ sở dữ liệu mới thay vì sử dụng công cụ xây dựng truy vấn vì đơn giản.

Thời gian dành cho việc nắm bắt các qwirks của một người xây dựng truy vấn (sau đó học lại khi bạn chuyển sang một cái tốt hơn) sẽ hiệu quả hơn nhiều khi học cách tối ưu hóa SQL của bạn.

Dù sao đó là lý do tại sao KHÔNG sử dụng một, mặc dù một số người yêu thích chúng.

Về mặt lý thuyết? Đúng. Glenn Nelson chỉ ra cách họ sẽ thường xuyên giúp bạn. (Nếu đó là một trình xây dựng truy vấn tốt).

Trong thực tế? Không phải lúc nào cũng sống theo lý thuyết và thực sự có thể gây ra vấn đề. Giả sử rằng bạn đang sử dụng một trình xây dựng truy vấn đối với một số DBMS phổ biến và mọi thứ đều rất hấp dẫn. Sau đó, một khách hàng yêu cầu bạn nhấn DBMS của họ có một số điểm mà trình xây dựng truy vấn bạn đã chọn không thể xử lý. (Tôi gặp vấn đề này khi tôi phải làm việc với phiên bản cũ hơn của Pervasive.)

NHƯNG! Điều bạn hoàn toàn nên làm là tách riêng Lớp truy cập dữ liệu và đảm bảo rằng bạn có thể trao đổi trong một lớp mới nếu cần. Bằng cách đó, bạn có thể xây dựng truy vấn tuyệt vời đó với tất cả các tính năng nhưng nếu bạn cần cắm một công cụ mới sử dụng giả ngẫu nhiên đó cho DB trong câu hỏi.

Tôi nghĩ rằng lợi ích thiết thực, hàng ngày của trình xây dựng truy vấn - là sử dụng lại mã và khả năng tuân theo nguyên tắc DRY.

Với trình xây dựng truy vấn, bạn có thể đặt các phần lặp lại của SQL vào các phương thức. Và sau đó sử dụng các phương thức này để soạn SQL phức tạp. Một ví dụ sẽ là ví dụ tái sử dụng mệnh đề THAM GIA:

function joinTaskWithClient($queryBuilder) {
    $queryBuilder->join('task', 'contract', 'task.contract_id = contract.id')
                 ->join('contract', 'client', 'contract.client_id = client.id');
}

Vì vậy, việc sử dụng sẽ là:

$queryBuilder->select('client.name')
             ->from('client')
             ->where('task.id=:task')->setParameter('task', 42);
joinTaskWithClient($queryBuilder);

Như bạn có thể lưu ý - với trình tạo truy vấn, bạn có thể thêm các phần của SQL theo bất kỳ thứ tự nào (ví dụ: THAM GIA một phần sau WHERE) trái ngược với trường hợp khi bạn thu thập chuỗi SQL theo cách thủ công. Ngoài ra, bạn có thể đọc về mẫu xây dựng để xem ý định và lợi ích của nó.

Tôi đồng ý về việc thoát và vệ sinh, nhưng điều này cũng có thể đạt được khi xây dựng truy vấn. Về loại trừu tượng DB / phương ngữ trừu tượng - đây là lợi ích khá lý thuyết và nghi vấn, hầu như không bao giờ được sử dụng trong thực tế.

tôi sẽ cung cấp câu trả lời dựa trên tệp readme của trình xây dựng SQL tùy chỉnh của tôi ( Phương ngữ )

(văn bản đơn giản theo sau, loại bỏ các tham chiếu cụ thể của thư viện)

Yêu cầu

1. Hỗ trợ nhiều nhà cung cấp DB (ví dụ: MySQL, PostgreSQL, SQLite, MS SQL / SQL Server, Oracle, DB2, ..)
2. Dễ dàng mở rộng sang các DB mới (tốt nhất là thông qua cài đặt cấu hình, không phụ thuộc vào triển khai)
3. Tính mô đun và khả năng chuyển giao độc lập
4. API linh hoạt và trực quan

Đặc trưng

1. mẫu dựa trên ngữ pháp
2. hỗ trợ lượt xem mềm tùy chỉnh
3. trừu tượng hóa db, mô đun hóa và khả năng chuyển nhượng
4. chuẩn bị mẫu
5. thoát dữ liệu

Tôi nghĩ rằng các tính năng và yêu cầu ở trên phác họa lý do người ta sẽ sử dụng trình xây dựng trừu tượng SQL

Hầu hết các tính năng trên được hỗ trợ bởi hầu hết các nhà xây dựng SQL (mặc dù tôi không nghĩ rằng tất cả các danh sách được hỗ trợ, theo hiểu biết của tôi)

Ví dụ về trường hợp sử dụng:

1. Nền tảng CMS có thể hoạt động (không thay đổi mã cơ bản) với nhiều nhà cung cấp DB
2. Mã ứng dụng tùy chỉnh trong đó nhà cung cấp DB có thể thay đổi và / hoặc các lược đồ dB là động (điều này có nghĩa là nhiều truy vấn không thể được mã hóa cứng nhưng vẫn cần được trừu tượng hóa đủ để mã mạnh mẽ thay đổi)
3. Tạo mẫu với một DB khác với một DB được sử dụng trong sản xuất (sẽ yêu cầu cơ sở mã trùng lặp ít nhất là đối với một số mã)
4. Mã ứng dụng không được kết hợp chặt chẽ với nhà cung cấp và / hoặc triển khai DB cụ thể (ngay cả trong cùng một nhà cung cấp DB, ví dụ: các phiên bản khác nhau của nhà cung cấp DB), do đó mạnh mẽ hơn, linh hoạt và mô đun hơn
5. Nhiều trường hợp truy vấn và thoát dữ liệu thông thường được xử lý bởi chính khung công tác và thông thường, điều này vừa tối ưu vừa nhanh hơn

Cuối cùng, một ví dụ về trường hợp sử dụng tôi đã có. tôi đang xây dựng một ứng dụng trong đó lược đồ DB cơ bản (wordpress) không phù hợp với loại truy vấn dữ liệu cần thực hiện, cộng với một số bảng WP (ví dụ: bài đăng) phải được sử dụng (vì vậy phải có bảng hoàn toàn mới cho tất cả các dữ liệu ứng dụng không phải là một lựa chọn).

Trong trường hợp đó, việc có thể tạo ra một ứng dụng giống như MVC trong đó mô hình có thể được truy vấn bởi các điều kiện tùy chỉnh / động khiến truy vấn mã hóa cứng gần như là một cơn ác mộng. Hãy tưởng tượng bạn phải hỗ trợ truy vấn có thể lên tới 2-3 bảng với các phép nối và lọc các điều kiện để xem bảng nào sẽ tham gia với cái gì và cũng quan tâm đến các bí danh cần thiết, v.v.

Rõ ràng đây là trường hợp sử dụng trừu tượng hóa truy vấn và thậm chí nhiều hơn, nó cần (hoặc ít nhất được hưởng lợi rất nhiều) có khả năng xác định các chế độ xem mềm tùy chỉnh (tập hợp các bảng đã tham gia như thể chúng là một bảng tùy chỉnh phù hợp với mô hình) . Sau đó, nó đã dễ dàng hơn nhiều, sạch hơn, mô-đun và linh hoạt. Trong một khía cạnh khác, ứng dụng (mã) cũng sử dụng lớp trừu tượng truy vấn như một công cụ chuẩn hóa (lược đồ db) . Như một số người nói, đó là bằng chứng trong tương lai .

Nếu, ngày mai, mọi người quyết định họ cần một số tùy chọn hoặc dữ liệu bổ sung, rất dễ dàng để thêm nó vào mô hình trong một vài dòng và hoạt động tốt. Ngoài ra, nếu, tommorow, mọi người quyết định họ không muốn sử dụng wordpress nữa (vì ứng dụng được ghép lỏng lẻo với wordpress như một plugin), việc thay đổi ( chỉ định nghĩa ) các mô hình trong một vài dòng cũng tương đối dễ dàng. mã để thích ứng với lược đồ mới.

Hiểu ý tôi chứ?

Rất thường xuyên, một số đối số cho các truy vấn này thực sự là một số giá trị chứ không phải là hằng số. Bây giờ, nhiều trong số chúng về cơ bản đã được bắt nguồn từ các bài đăng mẫu người dùng. Và do đó, có nhiều khả năng cho các cuộc tấn công tiêm SQL. Vì vậy, hình thành truy vấn vốn có yêu cầu xác nhận đầy đủ.

Bây giờ, điều này không có nghĩa là chúng tôi không tin tưởng nhà phát triển, nhưng việc hình thành truy vấn có thể dễ dàng, nhưng việc lặp lại tất cả các kiểm tra xác thực có thể xảy ra ở mọi nơi chỉ có thể ngụ ý rằng đôi khi bạn có thể bỏ lỡ tình cờ hoặc sửa đổi truy vấn nhưng không sửa đổi truy vấn nhưng không sửa đổi 't cập nhật kiểm tra xác nhận. Một số người mới thậm chí có thể biết tất cả những nguy hiểm của việc bỏ lỡ điều này. Do đó trừu tượng xây dựng truy vấn là khá cần thiết.

Tôi đã từng nghĩ rằng các trình xây dựng truy vấn là các ứng dụng GUI cho phép bạn chọn các bảng và tạo các phép nối bằng đồ họa trong khi tạo SQL trong trình duyệt, nhưng bây giờ tôi hiểu rằng bạn cũng gọi các trình xây dựng truy vấn các API cung cấp cách không phải tạo các truy vấn SQL thuần túy , vì vậy trừu tượng hóa bản thân về sự khác biệt tiềm năng trong các hương vị SQL.

Sử dụng các trình xây dựng truy vấn như vậy là tốt , nhưng tôi có xu hướng nghĩ rằng những người phụ thuộc nhiều vào họ có xu hướng không hỏi các DBA: "này, đây là một truy vấn tôi sử dụng rất nhiều, vui lòng tạo một cái nhìn từ đó".

Đừng hiểu lầm tôi.

Tôi nghĩ rằng bạn nên viết các truy vấn đối với các khung nhìn và không phải các bảng. Không phải vì bảo mật hoặc lọc, đó là những lý do tốt, nhưng vì lý do tương tự, bạn nên mã hóa các giao diện và không chống lại các lớp cụ thể: tách rời. Lượt xem giống như "hợp đồng", giao diện giống như "hợp đồng" trong OOP. Bạn có thể thay đổi các bảng bên dưới, nhưng miễn là bạn buộc các khung nhìn hiển thị cùng một "hợp đồng" cho các lập trình viên, mã không được phá vỡ.

Một lần nữa, đừng hiểu sai ý tôi, bạn có thể sử dụng các trình tạo truy vấn để truy vấn các chế độ xem, nhưng nhiều chế độ xem tồn tại như một quá trình điên rồ, là sản phẩm của việc phải viết truy vấn và yêu cầu DBA của bạn: "bạn ơi, hãy tạo cái này, làm ơn" .

Tôi có sai khi nghĩ rằng bằng cách không viết các truy vấn, bạn không phát hiện ra nhu cầu tạo ra các quan điểm nhất định?

Một điều nữa khiến tôi lo lắng là các lập trình viên mới làm quen không thành thạo SQL, một trong những phần công nghệ đẹp nhất do con người tạo ra, bằng cách không phải làm như vậy.