자바 프로그래밍-SQL 문을 어디에 저장해야합니까? [닫은]

JDBC 호환 응용 프로그램은 SQL 문을 어디에 저장해야하며 그 이유는 무엇입니까?

지금까지 다음 옵션을 확인했습니다.

• 비즈니스 객체에 하드 코딩 됨
• 에 포함 된 SQLJ의 절
• 별도의 클래스 (예 : 데이터 액세스 개체)로 캡슐화
• 메타 데이터 기반 (데이터 스키마에서 개체 스키마 분리-메타 데이터에서 개체 스키마 간의 매핑 설명)
• 외부 파일 (예 : 속성 또는 리소스 파일)
• 저장 프로 시저

각각의“장점”과“단점”은 무엇입니까?

SQL 코드는 "코드"또는 "메타 데이터"로 간주되어야합니까?

저장 프로시 저는 성능 최적화를 위해서만 사용해야합니까? 아니면 데이터베이스 구조의 합법적 인 추상화입니까?

성능이 결정의 핵심 요소입니까? 무엇에 대해 공급 업체에 종속 ?

더 나은 것은 무엇입니까-느슨한 결합 또는 단단한 결합 및 그 이유는 무엇입니까?

편집 됨 : 답변 해주신 모든 분들께 감사드립니다. 요약은 다음과 같습니다.

메타 데이터 기반 즉, 객체 관계형 매핑 (ORM)

장점 :

• 매우 추상적-모델 변경없이 DB 서버 전환 가능
• 광범위-실질적인 표준
• 필요한 SQL의 양을 줄입니다.
• 리소스 파일에 SQL 저장 가능
• 성능은 (일반적으로) 허용 가능합니다.
• 메타 데이터 기반 접근 방식
• (데이터베이스) 공급 업체 독립성

단점 :

• SQL 및 진정한 개발자 의도를 숨 깁니다.
• DBA가 검토 / 변경하기 어려운 SQL
• 이상한 경우에는 SQL이 여전히 필요할 수 있습니다.
• 독점 쿼리 언어 (예 : HQL)를 강제로 사용할 수 있습니다.
• 최적화 (추상화)에 적합하지 않음
• 참조 무결성이 부족할 수 있습니다.
• SQL 지식 부족 또는 DB의 코드 작성에 대한주의 부족을 대체합니다.
• 기본 데이터베이스 성능과 일치하지 않음 (가까워 지더라도)
• 모델 코드는 데이터베이스 모델과 매우 밀접하게 결합되어 있습니다.

DAO 레이어에서 하드 코딩 / 캡슐화 됨

장점 :

• SQL은 데이터에 액세스하는 객체에 보관됩니다 (캡슐화).
• SQL은 작성하기 쉽습니다 (개발 속도).
• SQL은 변경이 필요할 때 쉽게 추적 할 수 있습니다.
• 간단한 솔루션 (복잡한 아키텍처 없음)

단점 :

• SQL은 DBA가 검토 / 변경할 수 없습니다.
• SQL은 DB 전용이 될 가능성이 높습니다.
• SQL 유지 관리가 어려워 질 수 있음

저장 프로 시저

장점 :

• 데이터베이스에 보관 된 SQL (데이터에 가깝게)
• SQL은 DBMS에 의해 구문 분석, 컴파일 및 최적화됩니다.
• SQL은 DBA가 검토 / 변경하기 쉽습니다.
• 네트워크 트래픽 감소
• 보안 강화

단점 :

• SQL이 데이터베이스에 연결됨 (공급 업체 잠금)
• SQL 코드는 유지하기가 더 어렵습니다.

외부 파일 (예 : 속성 또는 리소스 파일)

장점

• 애플리케이션을 다시 빌드 할 필요없이 SQL을 변경할 수 있습니다.
• 애플리케이션 비즈니스 로직에서 SQL 로직 분리
• 모든 SQL 문의 중앙 저장소 – 유지 관리가 더 쉽습니다.
• 이해하기 더 쉬움

단점 :

• SQL 코드를 유지 관리 할 수 ​​없게 될 수 있음
• SQL 코드에서 (구문) 오류를 확인하기가 더 어렵습니다.

SQLJ 절에 포함

장점 :

• 더 나은 구문 검사

단점 :

• 자바와 너무 가깝게 연결
• JDBC보다 낮은 성능
• 동적 쿼리 부족
• 그렇게 인기가 없다

일반적으로 응용 프로그램의 크기 및 / 또는 재사용 가능성이 커질수록 SQL 문을 외부화 / 추상화해야 할 필요성이 더 커집니다.

하드 코딩 (정적 최종 상수)이 첫 번째 단계입니다. 다음 단계는 파일 (properties / xml 파일)에 저장됩니다. 메타 데이터 기반 (Hibernate / JPA와 같은 ORM에 의해 수행됨)이 마지막 단계입니다.

하드 코딩은 코드가 DB에 특화 될 가능성이 높고 변경 될 때마다 재 작성 / 재 구축 / 재배포해야한다는 단점이 있습니다. 장점은 한곳에 있다는 것입니다.

파일에 저장하면 응용 프로그램이 커지면 유지 관리가 불가능해질 수 있다는 단점이 있습니다. 장점은 추가 DAO 메서드를 추가 할 필요가없는 한 앱을 다시 작성 / 다시 빌드 할 필요가 없다는 것입니다.

메타 데이터 기반은 모델 코드가 데이터베이스 모델과 매우 밀접하게 결합되어 있다는 단점이 있습니다. 데이터베이스 모델이 변경 될 때마다 코드를 재 작성 / 재 작성 / 재배포해야합니다. 장점은 매우 추상적이며 모델을 변경할 필요없이 DB 서버에서 쉽게 전환 할 수 있다는 것입니다 (그러나 지금 자문 해보십시오 : 기업이 DB 서버에서 얼마나 자주 전환 할 것인가? 적어도 3 년에 한 번만 가능할 것입니다. t?).

저장 프로 시저를 이에 대한 "좋은"솔루션이라고 부르지 않겠습니다. 그들은 완전히 다른 목적을 가지고 있습니다. 하지만 코드는 사용 된 DB / 구성에 따라 달라집니다.

이것이 최적인지는 모르겠지만 내 경험상 DAO 레이어에서 하드 코딩 (즉, 문자열 리터럴)됩니다.

나는 그것이 다소 큰 질문이기 때문에 누구도 당신이 원하는 장단점을 줄 것이라고 생각하지 않습니다. 그래서 대신에 제가 과거에 사용한 것과 앞으로 사용할 것입니다.

DAL에 하드 코딩 된 SQL을 사용합니다. DBA가 SQL로 플레이하기 전까지는 이것이 괜찮다고 생각했습니다. 그런 다음 그것을 파 내고 포맷하고 DBA에게 보내야합니다. 누가 그것을 비웃고 대체 할 것인가. 그러나 좋은 물음표가 없거나 잘못된 순서의 물음표가 없으면 Java 코드에 다시 붙일 수 있습니다.

우리는 또한 ORM을 사용했고, 개발자에게는 좋은 방법이지만 DBA는 웃을 SQL이 없기 때문에이를 싫어했습니다. 우리는 또한 데이터베이스를 죽이는 버릇이있는 이상한 ORM (타사 공급 업체의 맞춤형 ORM)을 사용했습니다. 나는 그 이후로 JPA를 사용해 왔고 훌륭했지만 DBA를 지나서 JPA를 사용하여 복잡한 것을 얻는 것은 언덕 전투입니다.

이제 저장 프로 시저 (call 문이 하드 코딩 됨)를 사용합니다. 이제 모든 사람들이 가장 먼저 불평하는 것은 데이터베이스에 묶여 있다는 것입니다. 너는. 그러나 얼마나 자주 데이터베이스를 변경 했습니까? 저는 우리가 시도조차 할 수 없다는 사실을 알고 있습니다. 그것에 의존하는 다른 코드의 양과 DBA를 재교육하고 데이터를 마이그레이션하는 것입니다. 매우 비용이 많이 드는 작업입니다. 그러나 세계에서 DB를 변경하는 경우 모자 한 방울이 필요하면 SP가 나올 가능성이 높습니다.

앞으로는 코드 생성 도구와 함께 저장 프로 시저를 사용하여 Oracle 패키지에서 Java 클래스를 만들고 싶습니다.

편집 2013-01-31 : 몇 년 후 DBA와 이제 우리는 Hibernate를 사용하여 절대적으로 필요한 경우에만 SQL (DB에 저장된 procs)로 이동합니다. 이것이 최선의 해결책이라고 생각합니다. 99 %의 경우 DB는 SQL에 대해 걱정할 필요가 없으며 1 %는 이미 익숙한 장소에 있습니다.

ORM (예 : 최대 절전 모드)을 사용하면 걱정할 SQL 문 이 없을 것 입니다. 성능은 일반적으로 허용 가능하며 공급 업체의 독립성도 얻을 수 있습니다.

SQL 코드는 "코드"또는 "메타 데이터"로 간주되어야합니까?

암호.

저장 프로시 저는 성능 최적화를 위해서만 사용해야합니까? 아니면 데이터베이스 구조의 합법적 인 추상화입니까?

저장 프로시 저는 다른 저장 프로 시저 내부를 포함하여 다시 사용할 수 있습니다. 즉, 데이터베이스로 한 번 이동하여 지원 지침을 실행하도록 할 수 있습니다. 최소한의 트래픽이 이상적입니다. ORM 또는 sproc, db & back으로가는 와이어의 시간은 회수 할 수 없습니다.

ORM은 추상화 때문에 최적화에 적합하지 않습니다. IME, ORM은 또한 참조 무결성의 부족을 의미합니다. 데이터베이스를보고하기 어렵게 만듭니다. 복잡성으로 절약 된 것이 이제는 데이터를 실행 가능한 방식으로 가져올 수 있도록 증가했습니다.

성능이 결정의 핵심 요소입니까? 벤더 종속은 어떻습니까?

아니요, 단순합니다. 공급 업체 고정은 데이터베이스에서도 발생합니다. SQL은 상대적으로 표준화되었지만 여전히 공급 업체별 작업 방식이 있습니다.

자바 세계에서 벤더 종속에 대한 두려움은 흥미 롭습니다.

Oracle Enterprise에 대해 $ 50000 pr CPU를 지불하지 않았기를 바라며, 곧 Mysql로 ​​전환하기 위해 최소 공통 분모 만 사용했습니다. 좋은 DBA가 말하듯이, 특히 잠금 모델과 일관성을 달성하는 방법과 관련하여 서로 다른 유명 데이터베이스간에 미묘한 차이가 있습니다.

따라서 공급 업체에 구애받지 않는 SQL의 원칙에 따라서 만 SQL 호출을 구현하는 방법을 결정하지 마십시오. 실제 (비즈니스) 이유가 있어야합니다.

저장 프로 시저 내부의 SQL은 데이터베이스 시스템에 의해 최적화되고 속도를 위해 컴파일됩니다. 이것이 자연 스럽습니다. SQL은 데이터베이스 시스템에 의해 이해되고 데이터베이스 시스템에 의해 구문 분석됩니다. 가능하면 SQL을 데이터베이스에 보관하십시오. 저장 프로시 저나 함수 또는 데이터베이스 시스템이 제공하는 논리 단위로 래핑하고 사용자 또는 다른 사람이 언급 한 도구 중 하나를 사용하여 간단한 호출을 수행합니다.

DB 외부에 데이터베이스 시스템 용 SQL 코드를 저장하는 이유는 무엇입니까? 종종 개발 속도를 위해. ORM 매핑을 사용하는 이유는 무엇입니까? -일부는 ORM 매핑이 서로 다른 데이터베이스 시스템간에 호환성을 제공한다고 말합니다. 그러나 실제 세계에서는 응용 프로그램이 구축되었을 때 특히 복제와 같은 고급 기능을 사용하기 시작할 때 데이터베이스 플랫폼에서 벗어나는 경우가 거의 없으며 드물게 데이터베이스 시스템이 스왑 아웃되는 경우가 있으며 일부 작업이 보장됩니다. . 나는 ORM의 단점 중 하나가 종종 SQL 지식이 부족하거나 db에서 코드를 작성하는 데 신경을 쓰지 않는 것으로 대체한다고 생각합니다. 또한 ORM은 근접하더라도 기본 데이터베이스 성능과 일치하지 않습니다.

저는 데이터베이스에 SQL 코드를 유지하고 사용하려는 API 또는 인터페이스를 통해 간단한 호출을하는 편에 서 있습니다. 또한 이러한 호출을 추상 클래스 또는 OO 인터페이스 (메서드로 표현) 뒤에 배치하여 데이터베이스 호출이 수행되는 지점을 추상화하므로 새로운 종류의 데이터 소스에서 스왑을 수행하면 비즈니스 계층과 원활하게 연결됩니다. .

확실한 대답이있는 유일한 질문은 "SQL 코드입니까 아니면 메타 데이터입니까?"입니다. 가장 확실한 코드이므로 어떤 종류의 소스 코드 제어에 보관해야하며 문제가 발생 하지 않을 경우 최신 버전으로 쉽게 업데이트하고 롤백 할 수있는 시스템이 있어야합니다 .

응용 프로그램에서 SQL을 수행하는 세 가지 방법을 보았으며 각각 장단점이 있습니다. 최선의 방법은 없지만 가장 좋은 방법은 응용 프로그램과 잘 작동하는 방법을 선택하고이를 고수하는 것입니다.

• ORM-작성하는 데 필요한 SQL의 양을 줄이고 많은 세부 정보를 처리합니다. 사용자 지정 SQL을 수행해야합니다. 이를 우아하게 처리하는 ORM이 있는지 확인하십시오.
• 데이터 액세스 개체-데이터에 액세스하는 개체에 SQL을 유지합니다. 이렇게하면 데이터베이스가 캡슐화되고 나머지 애플리케이션이 기본 DB 구조에 대해 알 필요가 없으며 이러한 개체에 대한 인터페이스 만 알 수 있습니다.
• 저장 프로 시저-데이터베이스에 모든 SQL을 보관하고 DBA가 진행 상황을 쉽게 알 수 있습니다. 코드가 저장된 procs를 호출하도록하기 만하면됩니다.

우리는 Hibernate와 같은 ORM보다 금속에 더 가까운 iBatis SQL 매퍼를 사용합니다. iBatis에서는 클래스 경로에 있어야하는 리소스 파일 (XML)에 SQL 문을 넣습니다.

@ocdecio의 ORM 옵션을 추가하면 접근 방식 목록이 상당히 포괄적 인 것 같습니다. ORM을 사용하고 SQL 매퍼와 리소스 파일을 사용하는 것이 가장 좋은 두 가지 방법이라고 말할 수 있습니다. 나는 SQLJ를 분명히하겠다. SQLJ는 많은 이해를 얻지 못하고 Java와 너무 가깝게 연결되어 있습니다. 또한 저장 프로시 저는 특정 데이터베이스 공급 업체와 연결되어 있으므로 저장 프로 시저를 사용하지 마십시오 (저장 프로 시저에 대한 표준은 거의 존재하지 않음).

우리 대부분과 마찬가지로 나는 전체적인 gammut을 보았지만 SQL을 일류 언어로 고려해야합니다. DB에 저장된 SQL이 풀다운 된 다음 다시 실행되는 것을 본 적이 있습니다.

내가 본 가장 성공적인 시스템은 저장 프로 시저, 함수 및 뷰를 사용합니다.

저장된 procs는 SQL 텍스트를 다시 DB에 보관하고 배포 및 사용자 지정에 의해 상대적으로 즉각적인 변경을 허용합니다 (이를 지원하려면 많은 적절한 디자인이 필요함).

모든 프로젝션은 동일한 이유로 뷰와 단순 선택을 통해 이루어져야하며 모든 프로젝션 논리는 뷰 내에 포함되어야합니다.

공장 레이아웃과 함께 DAO를 사용하는 것이 좋습니다. 따라서 필요한 예제 개체는 다음과 같습니다.

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

이 스타일은 데이터 상호 작용을 계층화하므로 데이터베이스를 전환하거나 ORM 기술로 이동하는 경우 하나의 코드 계층 만 변경하면됩니다.

이 세 가지 사이에는 실질적인 차이가 없습니다.

1. 비즈니스 객체에 하드 코딩 됨
2. 에 포함 된 SQLJ의 절
3. 별도의 클래스 (예 : 데이터 액세스 개체)로 캡슐화

SQL 코드를 문자열 형식으로 Java 코드에 직접 포함한다고 가정합니다. 1과 3은 아마도 JDBC (또는 Apache DbUtils 와 같은 일부 도구)를 직접 사용하지만 2는 스택에 전 처리기 기술을 추가하여 컴파일 전에 관련 JDBC 코드를 생성합니다.

따라서 기본적으로 이러한 솔루션에 SQL 포함이 포함 된 경우 다음 기술 중 하나를 사용하는 것이 좋습니다.

• JPA Criteria API , JPQL을 Java의 내부 도메인 특정 언어로 모델링
• jOOQ , SQL을 Java의 내부 도메인 특정 언어로 모델링

SQLJ 또는 실제 문자열 연결을 통하는 것보다 더 형식이 안전한 방식으로 Java에 SQL을 임베드하는 데 도움이되는 다른 도구도있을 수 있습니다.

어떤 경험으로 보았을 때 DAO 개체에 SQL 문을 하드 코딩하는 것이 널리 사용되지만 가장 선호되지 않는 방법이라고 생각합니다. 가장 좋은 방법은 속성 파일에 SQL 문을 저장하는 것입니다. 그리고 java.util.Properties 와 같이 속성 파일에 대한 인터페이스를 통해 DAO 개체의 문을 가져옵니다 . SQL 문은 Prepared Statement 접근 방식을 통해 매개 변수를 전달하기 위해 '?'와 함께 산재 할 수 있습니다 .

이러한 접근 방식은 애플리케이션 비즈니스 로직에서 SQL 로직을 분리하는 데 도움이됩니다. 이를 통해 모든 SQL 문의 중앙 저장소를 사용할 수 있으므로 수정이 더 쉬워지고 애플리케이션 논리 내에서 데이터베이스 문을 검색 할 필요가 없습니다.

광산은 자원 번들로 끝납니다. 나는 그것이 정상적이지 않다는 것을 알고 있지만 그것은 나와 "나 이외의"사람이 유지하는 것이 가장 쉬운 방법입니다. 간단하고 논리적입니다.

누군가 내 접근 방식을 사용하는지 실제로 궁금합니다.

rexem 이 SQL 문을 작성한 것처럼 코드는 코드처럼 취급되어야하며 외부화 된 것이 아니라 (합당한 이유가없는 한) 해당 문에서 SQL 데이터를 처리하는 코드와 함께 배치되어야합니다. 오늘날의 프레임 워크 ORM / iBatis는 일상적인 JDBC 개발을위한 많은 단순화를 제공합니다.

질문에 대한 몇 가지 답변은 이 질문 에서 찾을 수 있습니다. SQL 구문이 저장되는 방법은 애플리케이션의 왕에 따라 다릅니다. 당신의 필요는 무엇입니까? 높은 보안 성, 코드 작성 또는 유지 관리 용이성, 크로스 플랫폼 또는 벤더 종속? 다음 질문은 순수한 SQL 또는 ORM 프레임 워크가 필요합니까?

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

가장 단순한 솔루션 (P), 유지 관리하기 어려움 (C)

* Embedded in SQLJ clauses

Beter 구문 검사 (P), 동적 쿼리 부족 (C), JDBC (C)보다 낮은 성능, 인기 없음 (C)

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

(C) 또는 ORM을 의미하는 경우 (P);)

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

관리하기 쉽지만 (P) 오류를 확인하기가 더 어렵습니다 (C).

* Stored Procedures

높은 보안 성 (P), 공급 업체 종속 문제를 해결하기 어려운 코드 (C)