Lập trình Java - Câu lệnh SQL nên được lưu trữ ở đâu? [đóng cửa]

Một ứng dụng tuân thủ JDBC nên lưu trữ các câu lệnh SQL của nó ở đâu và tại sao?

Cho đến nay, tôi đã quản lý để xác định các tùy chọn này:

• Mã cứng trong các đối tượng kinh doanh
• Được nhúng trong mệnh đề SQLJ
• Đóng gói trong các lớp riêng biệt, ví dụ: Đối tượng truy cập dữ liệu
• Theo hướng siêu dữ liệu (tách lược đồ đối tượng khỏi lược đồ dữ liệu - mô tả ánh xạ giữa chúng trong siêu dữ liệu)
• Các tệp bên ngoài (ví dụ: Thuộc tính hoặc tệp Tài nguyên)
• Thủ tục lưu trữ

"Ưu điểm" và "Nhược điểm" cho mỗi cái là gì?

Mã SQL nên được coi là “mã” hay “siêu dữ liệu”?

Các thủ tục được lưu trữ có nên được sử dụng chỉ để tối ưu hóa hiệu suất hay chúng là một cấu trúc cơ sở dữ liệu trừu tượng hợp pháp?

Hiệu suất có phải là yếu tố quyết định không? Điều gì về khóa nhà cung cấp ?

Điều gì là tốt hơn - khớp nối lỏng lẻo hoặc khớp nối chặt chẽ và tại sao?

ĐÃ CHỈNH SỬA: Cảm ơn mọi người vì câu trả lời - đây là bản tóm tắt:

Điều khiển siêu dữ liệu tức là Ánh xạ quan hệ đối tượng (ORM)

Ưu điểm:

• Rất trừu tượng - Máy chủ DB có thể được chuyển đổi mà không cần thay đổi mô hình
• Phạm vi rộng - thực tế là một tiêu chuẩn
• Cắt giảm lượng SQL cần thiết
• Có thể lưu trữ SQL trong các tệp tài nguyên
• Hiệu suất (thường) chấp nhận được
• Phương pháp tiếp cận theo hướng siêu dữ liệu
• (Cơ sở dữ liệu) độc lập với nhà cung cấp

Nhược điểm:

• Ẩn SQL và ý định thực sự của nhà phát triển
• SQL khó được DBA xem xét / thay đổi
• SQL có thể vẫn cần thiết cho các trường hợp kỳ quặc
• Có thể buộc sử dụng ngôn ngữ truy vấn độc quyền, ví dụ như HQL
• Không tự cho mình tối ưu hóa (trừu tượng hóa)
• Có thể thiếu tính toàn vẹn tham chiếu
• Thay thế cho việc thiếu kiến ​​thức SQL hoặc thiếu cẩn thận để viết mã trong DB
• Không bao giờ khớp với hiệu suất cơ sở dữ liệu gốc (ngay cả khi nó đến gần)
• Mã mô hình rất chặt chẽ kết hợp với mô hình cơ sở dữ liệu

Được mã hóa cứng / đóng gói trong lớp DAO

Ưu điểm:

• SQL được giữ trong các đối tượng truy cập dữ liệu (đóng gói)
• SQL rất dễ viết (tốc độ phát triển)
• SQL dễ theo dõi khi cần thay đổi
• Giải pháp đơn giản (không có kiến ​​trúc lộn xộn)

Nhược điểm:

• SQL không thể được xem xét / thay đổi bởi DBA
• SQL có khả năng trở thành DB cụ thể
• SQL có thể trở nên khó bảo trì

Thủ tục lưu trữ

Ưu điểm:

• SQL được giữ trong cơ sở dữ liệu (gần với dữ liệu)
• SQL được phân tích cú pháp, biên dịch và tối ưu hóa bởi DBMS
• SQL dễ dàng để DBA xem xét / thay đổi
• Giảm lưu lượng mạng
• Tăng cường an ninh

Nhược điểm:

• SQL được gắn với cơ sở dữ liệu (khóa nhà cung cấp)
• Mã SQL khó duy trì hơn

Các tệp bên ngoài (ví dụ: Thuộc tính hoặc tệp Tài nguyên)

Ưu điểm

• SQL có thể được thay đổi mà không cần phải xây dựng lại ứng dụng
• Tách logic SQL khỏi logic nghiệp vụ ứng dụng
• Kho lưu trữ trung tâm của tất cả các câu lệnh SQL - dễ bảo trì hơn
• Dễ hiểu

Nhược điểm:

• Mã SQL có thể trở nên không thể bảo trì được
• Khó kiểm tra mã SQL để tìm lỗi (cú pháp)

Được nhúng trong mệnh đề SQLJ

Ưu điểm:

• Kiểm tra cú pháp tốt hơn

Nhược điểm:

• Liên kết quá chặt chẽ với Java
• Hiệu suất thấp hơn JDBC
• Thiếu truy vấn động
• Không phổ biến lắm

Thông thường, ứng dụng càng phát triển về kích thước và / hoặc khả năng tái sử dụng, thì nhu cầu ngoại hóa / trừu tượng hóa các câu lệnh SQL càng nhiều.

Hardcoded (dưới dạng hằng số tĩnh cuối cùng) là bước đầu tiên. Lưu trữ trong một tệp (thuộc tính / tệp xml) là bước tiếp theo. Điều khiển siêu dữ liệu (được thực hiện bởi ORM như Hibernate / JPA) là bước cuối cùng.

Hardcoded có nhược điểm là mã của bạn có khả năng trở thành dành riêng cho DB và bạn cần phải viết lại / xây dựng lại / phân phối lại mỗi lần thay đổi. Lợi thế là bạn có nó ở 1 nơi.

Được lưu trữ trong một tệp có nhược điểm là nó có thể trở nên không thể truy cập được khi ứng dụng phát triển. Ưu điểm là bạn không cần phải viết lại / xây dựng lại ứng dụng, trừ khi bạn cần thêm một phương thức DAO bổ sung.

Điều khiển siêu dữ liệu có nhược điểm là mã mô hình của bạn kết hợp rất chặt chẽ với mô hình cơ sở dữ liệu. Đối với mọi thay đổi trong mô hình cơ sở dữ liệu, bạn sẽ cần viết lại / xây dựng lại / phân phối lại mã. Ưu điểm là nó rất trừu tượng và bạn có thể dễ dàng chuyển đổi từ máy chủ DB mà không cần phải thay đổi mô hình của mình (nhưng hãy tự hỏi bản thân ngay bây giờ: tần suất một công ty chuyển từ máy chủ DB là bao lâu? Có thể ít nhất chỉ một lần mỗi 3 năm, isn ' t nó?).

Tôi sẽ không gọi các thủ tục được lưu trữ là giải pháp "tốt" cho việc này. Họ có một mục đích hoàn toàn khác. Mặc dù vậy, mã của bạn sẽ phụ thuộc vào DB / cấu hình được sử dụng.

Tôi không biết liệu điều này có phải là tối ưu hay không, nhưng theo kinh nghiệm của tôi, chúng kết thúc được mã hóa cứng (tức là chuỗi ký tự) trong lớp DAO.

Tôi không nghĩ rằng bất cứ ai sẽ cung cấp cho bạn sự phá vỡ chuyên nghiệp / con bạn muốn vì nó là một câu hỏi khá lớn. Vì vậy, thay vào đó, đây là những gì tôi đã sử dụng trong quá khứ và những gì tôi sẽ sử dụng trong tương lai.

Tôi sử dụng để sử dụng mã cứng SQL trong DAL. Tôi nghĩ rằng điều này là tốt cho đến khi các DBA muốn chơi với SQL. Sau đó, bạn phải đào nó ra, định dạng nó và chuyển nó sang DBA. Ai sẽ cười nó và thay tất cả. Nhưng không có dấu chấm hỏi đẹp, hoặc dấu hỏi không đúng thứ tự và khiến bạn phải gắn nó lại trong mã Java.

Chúng tôi cũng đã sử dụng ORM, và mặc dù điều này rất tốt cho các nhà phát triển DBA của chúng tôi ghét nó vì không có SQL để họ cười. Chúng tôi cũng sử dụng một ORM kỳ quặc (một ORM tùy chỉnh từ nhà cung cấp bên thứ 3) có thói quen giết cơ sở dữ liệu. Tôi đã sử dụng JPA kể từ đó và rất tuyệt vời, nhưng việc sử dụng nó bất cứ thứ gì phức tạp trong quá khứ DBA là một cuộc chiến khó khăn.

Bây giờ chúng tôi sử dụng Thủ tục lưu trữ (với câu lệnh gọi được mã hóa cứng). Bây giờ điều đầu tiên mà mọi người sẽ phàn nàn là bạn bị ràng buộc với cơ sở dữ liệu. Bạn là. Tuy nhiên bạn đã thay đổi cơ sở dữ liệu bao lâu một lần? Tôi biết thực tế là chúng tôi thậm chí không thể thử nó, số lượng mã khác phụ thuộc vào nó cộng với việc đào tạo lại DBA của chúng tôi cộng với việc di chuyển dữ liệu. Nó sẽ là một hoạt động rất tốn kém. Tuy nhiên, nếu trong thế giới của bạn thay đổi DBs mà không cần thiết thì các SP có thể bị loại bỏ.

Trong tương lai, tôi muốn sử dụng các thủ tục được lưu trữ với các công cụ tạo mã để tạo các lớp Java từ các gói Oracle.

Chỉnh sửa 2013-01-31 : Vài năm sau và DBAs và bây giờ chúng tôi sử dụng Hibernate, chuyển sang SQL (procs được lưu trữ trong DB) chỉ khi thực sự cần thiết. Điều này tôi nghĩ là giải pháp tốt nhất. 99% các DB không cần phải lo lắng về SQL và 1% họ làm điều đó ở một nơi mà họ đã cảm thấy thoải mái.

Bằng cách sử dụng ORM (chẳng hạn như hibernate), bạn hy vọng sẽ không có câu lệnh SQL nào phải lo lắng. Hiệu suất thường được chấp nhận và bạn cũng nhận được sự độc lập của nhà cung cấp.

Mã SQL nên được coi là “mã” hay “siêu dữ liệu”?

Mã.

Các thủ tục được lưu trữ có nên được sử dụng chỉ để tối ưu hóa hiệu suất hay chúng là một cấu trúc cơ sở dữ liệu trừu tượng hợp pháp?

Các thủ tục được lưu trữ cho phép sử dụng lại, bao gồm cả bên trong các thủ tục được lưu trữ khác. Điều này có nghĩa là bạn có thể thực hiện một chuyến đi đến cơ sở dữ liệu và để nó thực thi các hướng dẫn hỗ trợ - lý tưởng là lưu lượng truy cập ít nhất. ORM hoặc Spc, thời gian lên dây về db ​​& back là điều bạn không thể lấy lại được.

ORM không tự cho mình tối ưu hóa vì tính trừu tượng của nó. IME, ORM cũng có nghĩa là thiếu tính toàn vẹn tham chiếu - làm cho cơ sở dữ liệu khó báo cáo. Những gì đã được lưu trong độ phức tạp, giờ đây đã tăng lên để có thể lấy dữ liệu ra theo cách khả thi.

Hiệu suất có phải là yếu tố quyết định không? Điều gì về khóa nhà cung cấp?

Không, đơn giản là vậy. Khoá của nhà cung cấp cũng xảy ra với cơ sở dữ liệu - SQL tương đối được tiêu chuẩn hoá, nhưng vẫn có những cách thực hiện cụ thể của nhà cung cấp.

Nỗi sợ hãi về việc nhà cung cấp bị khóa trong thế giới java thật thú vị.

Tôi hy vọng bạn chưa trả $ 50000 pr CPU cho Oracle Enterprise và sau đó chỉ sử dụng mẫu số chung nhỏ nhất để chuyển sang Mysql bất kỳ phút nào. Như bất kỳ DBA tốt nào sẽ cho bạn biết, có sự khác biệt nhỏ giữa các cơ sở dữ liệu tên tuổi khác nhau, đặc biệt là về mô hình khóa và cách chúng đạt được tính nhất quán.

Vì vậy, đừng đưa ra quyết định về cách triển khai các lệnh gọi SQL của bạn chỉ dựa trên nguyên tắc SQL bất khả tri của nhà cung cấp - hãy có lý do thực sự (kinh doanh) để làm như vậy.

SQL bên trong Thủ tục được lưu trữ được tối ưu hóa bởi hệ thống cơ sở dữ liệu và được biên dịch để tăng tốc độ - đó là ngôi nhà tự nhiên của nó. SQL được hiểu bởi hệ thống cơ sở dữ liệu, được phân tích cú pháp bởi hệ thống cơ sở dữ liệu. Giữ SQL của bạn trong cơ sở dữ liệu nếu bạn có thể; bọc nó trong các thủ tục hoặc hàm được lưu trữ hoặc bất kỳ đơn vị logic nào mà hệ thống cơ sở dữ liệu cung cấp và thực hiện các lệnh gọi đơn giản đến nó bằng bất kỳ công cụ nào mà bạn hoặc bất kỳ ai khác đã đề cập.

Tại sao phải lưu trữ mã SQL cho hệ thống cơ sở dữ liệu bên ngoài db? Thường cho tốc độ phát triển. Tại sao sử dụng ánh xạ ORM? - Một số người nói ánh xạ ORM cung cấp khả năng tương thích trên các hệ thống cơ sở dữ liệu khác nhau; tuy nhiên hiếm khi trong thế giới thực một ứng dụng nào đó rời khỏi nền tảng cơ sở dữ liệu khi nó được xây dựng, đặc biệt là khi nó bắt đầu sử dụng các tính năng nâng cao như sao chép và trong một số trường hợp hiếm hoi xảy ra trường hợp hệ thống cơ sở dữ liệu bị hoán đổi, một số công việc được đảm bảo . Tôi tin rằng một trong những nhược điểm của ORM, nó thường thay thế cho việc thiếu kiến ​​thức SQL hoặc thiếu cẩn thận để viết mã trong db. Ngoài ra ORM sẽ không bao giờ khớp với hiệu suất cơ sở dữ liệu gốc ngay cả khi nó đến gần.

Tôi đang đứng về phía giữ mã SQL trong cơ sở dữ liệu và thực hiện các lệnh gọi đơn giản đến nó thông qua bất kỳ API hoặc giao diện nào bạn muốn sử dụng. Đồng thời trừu tượng hóa điểm mà tại đó các lệnh gọi cơ sở dữ liệu của bạn được thực hiện bằng cách đặt các lệnh gọi đó sau một lớp trừu tượng hoặc giao diện OO (được thể hiện bằng các phương thức), vì vậy nếu bạn hoán đổi trong một loại nguồn dữ liệu mới, nó sẽ liền mạch với lớp nghiệp vụ .

Câu hỏi duy nhất bạn hỏi có câu trả lời chắc chắn là "Là mã SQL hay siêu dữ liệu?" Nó chắc chắn nhất là mã và như vậy nên được giữ trong một số loại kiểm soát mã nguồn và có một hệ thống để dễ dàng cập nhật lên phiên bản mới nhất và quay lại khi không xảy ra sự cố.

Tôi đã thấy ba cách thực hiện SQL trong một ứng dụng và mỗi cách đều có ưu và nhược điểm. Không có cách nào tốt nhất, nhưng điều tốt nhất là chỉ cần chọn một cách hoạt động tốt với ứng dụng của bạn và gắn bó với nó.

• ORM - điều này cắt giảm lượng SQL bạn cần viết và xử lý rất nhiều chi tiết cho bạn. Bạn sẽ cần thực hiện một số SQL tùy chỉnh. Đảm bảo bạn có ORM xử lý việc này một cách linh hoạt.
• Đối tượng truy cập dữ liệu - giữ SQL trong các đối tượng truy cập dữ liệu. Điều này đóng gói cơ sở dữ liệu của bạn và làm cho nó để phần còn lại của ứng dụng của bạn không cần biết về cấu trúc DB bên dưới, chỉ cần giao diện với các đối tượng này.
• Thủ tục lưu trữ - điều này giữ tất cả SQL của bạn trong cơ sở dữ liệu và giúp DBA của bạn dễ dàng biết được điều gì đang xảy ra. Tất cả những gì bạn cần làm là gọi mã của bạn đến các procs được lưu trữ

Chúng tôi tình cờ sử dụng trình ánh xạ iBatis SQL, gần với kim loại hơn các ORM như Hibernate. Trong iBatis, bạn đặt các câu lệnh SQL vào các tệp tài nguyên (XML), các tệp này cần phải nằm trong classpath.

Danh sách các phương pháp tiếp cận của bạn có vẻ khá toàn diện nếu bạn thêm tùy chọn ORM của @ ocdecio. Tôi muốn nói rằng sử dụng ORM và sử dụng trình ánh xạ SQL và các tệp tài nguyên là hai cách tiếp cận tốt nhất. Tôi muốn tránh xa SQLJ, vốn không được nhiều người quan tâm và ràng buộc bạn quá chặt chẽ với Java. Cũng tránh xa các thủ tục được lưu trữ, vì chúng ràng buộc bạn với một nhà cung cấp cơ sở dữ liệu cụ thể (các tiêu chuẩn hầu như không tồn tại cho các thủ tục được lưu trữ).

Giống như hầu hết chúng ta, tôi đã thấy toàn bộ âm giai nhưng chúng ta cần coi SQL là một ngôn ngữ hạng nhất. Tôi thậm chí đã thấy SQL được lưu trữ trong DB được kéo xuống sau đó được thực thi sao lưu.

Các hệ thống thành công nhất mà tôi đã thấy sử dụng các thủ tục, chức năng và khung nhìn được lưu trữ.

Các procs được lưu trữ giữ văn bản SQL trở lại DB và cho phép thay đổi tương đối ngay lập tức bằng cách TRIỂN KHAI và TÙY CHỈNH đó (đòi hỏi nhiều thiết kế thích hợp để hỗ trợ nó).

Tất cả các phép chiếu phải thông qua các khung nhìn và các lựa chọn đơn giản vì những lý do giống nhau, tất cả logic của phép chiếu phải được chứa trong khung nhìn.

Tôi đề nghị sử dụng DAO với bố cục nhà máy. Vì vậy, các đối tượng ví dụ bạn cần sẽ là:

public class CoolBusinessObject
public class DAOFactory.java
public implementation CoolBusinessOjectDAO
public class CoolBusinessOjectDAOOracleImpl implements CoolBusinessOjectDAO

Kiểu này tạo lớp tương tác dữ liệu, vì vậy bạn chỉ phải thay đổi một lớp mã nếu bạn chuyển đổi cơ sở dữ liệu hoặc chuyển sang công nghệ ORM.

Thực sự không có bất kỳ sự khác biệt đáng kể nào giữa ba điều này:

1. Mã cứng trong các đối tượng kinh doanh
2. Được nhúng trong mệnh đề SQLJ
3. Đóng gói trong các lớp riêng biệt, ví dụ: Đối tượng truy cập dữ liệu

Tôi giả định rằng bạn sẽ nhúng mã SQL ở dạng chuỗi trực tiếp vào mã Java của mình. Trong khi 1 và 3 có thể sẽ sử dụng JDBC trực tiếp (hoặc một số công cụ như Apache DbUtils ), 2 thêm một công nghệ tiền xử lý vào ngăn xếp, tạo mã JDBC có liên quan trước khi biên dịch.

Vì vậy, về cơ bản, nếu các giải pháp này liên quan đến việc nhúng SQL, bạn cũng có thể sử dụng bất kỳ công nghệ nào sau đây:

• API tiêu chí JPA , lập mô hình JPQL như một ngôn ngữ dành riêng cho miền nội bộ trong Java
• jOOQ , lập mô hình SQL như một ngôn ngữ dành riêng cho miền nội bộ trong Java

Cũng có thể có các công cụ khác giúp bạn nhúng SQL vào Java theo cách an toàn về kiểu chữ hơn là thông qua SQLJ hoặc thông qua nối chuỗi thực tế.

Theo kinh nghiệm, tôi đã có, các câu lệnh sql mã hóa cứng trong các đối tượng DAO là thứ được sử dụng rộng rãi, tuy nhiên, tôi nghĩ nó phải là phương pháp ít được ưa thích nhất. Cách tốt nhất là lưu trữ các câu lệnh sql trong một tệp thuộc tính. Và lấy các câu lệnh trong đối tượng DAO thông qua một giao diện với các tệp thuộc tính, chẳng hạn như java.util.Properties . Các câu lệnh sql có thể được xen kẽ với '?' Để chuyển các tham số, thông qua một Câu lệnh Chuẩn bị cách tiếp cận .

Cách tiếp cận như vậy giúp tách logic sql khỏi logic nghiệp vụ ứng dụng. Điều này cung cấp một kho lưu trữ trung tâm của tất cả các câu lệnh sql, giúp sửa đổi dễ dàng hơn, loại bỏ nhu cầu tìm kiếm các câu lệnh cơ sở dữ liệu trong logic ứng dụng.

Cuối cùng của tôi trong các gói tài nguyên. Tôi biết điều đó không bình thường nhưng đó là điều dễ dàng nhất đối với tôi và bất kỳ ai "ngoài tôi" để duy trì. Nó đơn giản và logic.

Tôi thực sự tò mò muốn biết liệu có ai cũng sử dụng cách tiếp cận của tôi không.

Như một rexem đã viết, các trạng thái SQL là mã - chúng phải được coi như mã, không được ngoại hóa (trừ khi bạn có lý do chính đáng) nhưng được đặt với mã xử lý dữ liệu SQL từ / đến các câu lệnh đó. Khung Todays ORMs / iBatis cung cấp rất nhiều đơn giản hóa để phát triển JDBC hàng ngày.

Một số câu trả lời cho câu hỏi của bạn mà bạn sẽ tìm thấy trong câu hỏi này :) Vấn đề làm thế nào các trạng thái SQL của bạn sẽ được lưu trữ phụ thuộc vào vua của ứng dụng của bạn. Nhu cầu của bạn là gì? Bảo mật cao, dễ viết mã hoặc bảo trì, định dạng chéo hoặc khóa nhà cung cấp? Câu hỏi tiếp theo bạn cần SQL thuần túy hay khung ORM sẽ tốt?

* Hardcoded in business objects
* Encapsulate in separate classes e.g. Data Access Objects

Dung dịch đơn giản nhất (P), khó duy trì (C)

* Embedded in SQLJ clauses

Kiểm tra cú pháp Beter (P), thiếu truy vấn động od (C), hiệu suất thấp hơn JDBC (C), không quá phổ biến (C)

* Metadata driven (decouple the object schema from the data schema - describe the mappings between them in metadata)

Đó phải là trường hợp cụ thể bạn nên làm điều đó (C) hoặc nếu bạn có nghĩa là ORM (P);)

* External files (e.g. Properties or Resource files)

Dễ nhớ (P) nhưng khó kiểm tra lỗi hơn (C)

* Stored Procedures

Độ bảo mật cao (P), mã khó giải quyết vấn đề khóa nhà cung cấp (C)